Memory issues of MSP microcontrollers

fish001

Memory issues of MSP microcontrollers [Copy link]

This is a very serious question. If ADC is a hidden task of power consumption, then this is a hidden boss that shakes the foundation of your entire program structure. Either you don't encounter it, or if you encounter it, you're over, because this is not a monster upgrade. Let's take a look at a warning first: Maybe some people will never encounter this problem in their lifetime. This problem is very annoying. What is called accessing an odd address? ? ? This problem is similar to the brute force access to a certain memory address on the computer. When I encountered this problem, I felt like my balls were being pinched in someone's hand. Fortunately, mc_wangbo, an expert, gave me some advice. First, we need to determine where this address is. Since 430 is a von Neumann structure, the program memory and data memory are together. According to the user manual, 0x0200 and above are RAM, of course, it depends on the size. Because I was using msp430f4152 at that time, the RAM is 512B, that is, 0x0200~0x0400 is the RAM area, and 0x0400 and above is the code area, so there is a problem with the code area. Then explain the problem of odd addresses. The following is a paragraph about memory organization from the user manual: The above means that byte data can be located at odd addresses and even addresses, while word data can only be located at even addresses! ! ! What does it mean? msp430 is a 16-bit microcontroller, and its one word is 2 bytes. Although it is a 16-bit microcontroller, it still stores in half-word mode. Its one address actually corresponds to a byte, not a word! ! ! That is to say, its storage method is still 8-bit (the advantage of this storage method is that it does not waste RAM), but it can process 2 8-bit data at a time...so the address must distinguish between odd and even! Because the storage method is little-endian, the high 8 bits of 16-bit data are stored at high addresses and the low 8 bits are stored at low addresses, but the low addresses must be even addresses!!! Then the situation is roughly clear. According to the compiler compilation results, generally, simple instructions will not have such vulnerabilities. The only possibility is that there is a problem with the constants defined in the code area, that is, the variables with const added in front!!! Why? Because the compiler is not that smart, suppose the constant variable you define is an array of unsigned char type with const, such as x[4]={0x12,0x34,0x56,0x78}; the compiler sees that you define 8 bits, and it will use MOV.B (half-word instruction) to store this array constant, assuming that it is stored at 0xc120, 0xc121, 0xc122, and 0xc123. This is understandable, but if you force these 4 numbers to be converted into an unsigned char, an unsigned int and an unsigned char structure in the program (don’t say no, pointers are a wonderful thing), then the hidden boss will wave the sickle to harvest souls like the god of death. When using this structure, the microcontroller first uses MOV.B to call the first unsigned char number, which is 0x12 on 0xc120, and then uses MOV.W to call the second unsigned int number, which is 0xc121 and 0xc122. The number is 0x5634, but in fact it is wrong because the low address is stored at the odd address 0xc121!!! MOV.W cannot access the odd address!!! That is to say, the MCU will not access the address 0xc121 at all, but will skip 0xc121 and directly fetch data from 0xc122, and the data fetched is 0x7856!!! It's a rip-off!!! And this warning will not go wrong when compiling!!! It will not go wrong when downloaded to the MCU, and it can still run!!! The compiler will only go wrong when emulating the software!!! The best solution is not to do this, the compiler will not go wrong, and it will not deliberately allocate addresses like this, so when you define a half-word array and force a type conversion in the program, you must pay special attention. If you want to define each array to an even address, you can add @0xc120 after the array after defining the array, so that the array will be defined at the beginning of this address.

hustjtj0806

It seems that there are still some problems with TI's compiler. For this kind of problem, the compiler should give a warning and provide a solution.