Thanks for the info. The 54xx header files should be mostly fine by now. So this shouldn't be a problem. Also, even the older MSPGCC builds shouldn't have problem with the memory locations as long as the resulting text segment fits below 64k. The compiler does not generate absolute addresses, so it is also possible to put arrays or other sparsely used data into another segment that is located above 64k. You'd have to embed a separate inline assembly function to access the data (with manually created 430X code). There was one published here some time ago. Witht he proper linker definitions, the linker shouldn't have a problem building up a proper hex file (even with segments above 64k).
(note the 'should's above, I never tested it myself) BUT the normal JTAG tool does not know about hex files with >64k address range. And the older jtag library (which does the communication) knows neither the extended address range nor the changed hardware adresses for the FLASH controller. So how to program the compiled code into the devices? One could use the bootstrap loader, but htis is a bit tricky, as 1) you'd need a serial interface with voltage converter for accessing it and 2) the required password depends on the interrupt table of the last code you flashed. So it changes constantly and you need to know which version of the firmware is already on it. A service nightmare if the product is still under development. Currently, the memory is not my problem. I need the additional comm modules, the higher frequency, the increased number of I/O ports and the lower price :) If there was a non-430X-version of the 541x/3x devices, I'd be fine with it. JMGross ----- Ursprüngliche Nachricht ----- Von: [email protected] An: [email protected] Gesendet am: 07 Aug 2009 18:31:19 Betreff: Re: using JTAG debugger - several issues Here's what I'm doing successfully re. 5x processor but no 430X extensions. I'll provide more detail if your'e interested. This works for me but perhaps not so elegant. I've created my own very basic header file for 543x/541x which includes all the sfr definitions with appropriate size (b/w) - not included are the various bit definitions which I tend not to use much anyway (although I've added quite a few over time). Include this file but NOT io.h which is what brings in the mspgcc header file (msp430x54xx.h). The mspgcc defs get linked in later, but they just show up in the map listing and don't hurt anything. You can copy anything else useful you want from io.h or msp430x54xx.h (even the IAR header files) to get int vectors and such. I figure if the mspgcc include gets completed someday I'll switch to that. You do need a recent enough build (win or Linux) to get the memory locations to compile correctly. I'm using win (mspgcc-20081230.exe). I'm just hitting the memory limit with my app, so trying to figure out how to deal with that. It will likely be some simple trickery since I don't trust any of the tool chain versions yet and no one seems to be pushing them to completion. Cheers, Spencer Allen
