TMS470MF03107: The RAM space required by the program after compilation is 0x5178 bytes, which is larger than the size of a single RAM area 0x08000000-0x08003FFF. Based on the current memory space resources, how to deal with it to meet the memory requiremen

Thx for your early reply!  Maybe I need further help.

Charles Tsai said:

Again, 9000+11856=20856 bytes. This is more than the 16kB of RAM available on the chip. There is also stack that will need to reside on the RAM.  Are these all dynamic data that must be saved on the RAM? I don't know about your application but you must figure out a way to reduce the RAM usage.  There is really not anything I can offer other than to reduce the RAM usage.

chenyuefeng said:

After compiling of out programme(for ABS application with TPMS function)，the memory allocation is as follows,which I recognised as static Memory occupation.You can see the child items under parent"RAM"is .bss and .data,during which dynamic RAM occupation is not included yet.Once dynamic RAM is added based on the static allocation, the  real-time RAM occupation is far more than what the picture below shows for RAM? Am I put it right about the understanding about the RAM occupation after compiling and after program running,that is,static and dynamic RAM occupation?

OR do you mean the total RAM memory for program running use is just only the space between 0x08000000-0x08003FFF?

chenyuefeng said:

No, you cannot do this. The 0x08080000-0x08083FFF is a alias address range for the RAM as a "SET" space. When you write to this space, it will only change from 0 to 1. Whatever value that is already a 1 cannot be changed to a 0. This is a alias space to alleviate program from doing read-modify-write operations to save cycles. This space is similar to registers where you can write a 1 to set a bit on a "SET" alias and write a 1 to clear a bit on a "CLEAR" alias address. As 

chenyuefeng said:

I am sorry I didn't see your answering content after "As".Anything else about your answering?

chenyuefeng said:

What is iTPMS_G101_NEW_1101.lib? Why is this mapped to RAM, not flash? 

 You can look at the map file to understand where each symbol/function is allocated in the memory;

chenyuefeng said:

"iTPMS_G101_NEW_1101.lib" is a .lib file which include some function APIs for use in our ABS with TPMS applications.

It is not only  mapped into the flash,but also RAM,which you can see above：

A s you also said,based on the memory allocation method above,no matter the total space defined for RAM in the linkCMD(22528 bytes) or the actual occupation space of the RAM(20853 bytes),  both are more than the total space 0x3FFF(address from 0x08000000 to 0x08003FFF) the chip can offer，which indicates that RAM is already out of range before program running.That means that Once program running start,  additional RAM space is needed? 

But RAM space for program occupation is no more than 0x3FFF. So can you tell me the chip operational principle about why the program can still run without any other additional RAM space available,meanwhile with already overflowing  RAM occupation just before program run?  

Here it says that you use 2560bytes for stack and 20853 bytes for .bss and .data. Your .bss is 19448 bytes. This .bss section are used for statically allocated variables that are declared but have not been assigned a value yet. As far as I can tell, this is not a dynamic allocated allocated. Dynamic memory allocation are heap memory when you use malloc(). 

Do you really need to reserve 19448 bytes of spaces in RAM? It is your application, only you can tell if this is absolutely needed. It is like you are creating a global variable as follows. 

uint8_t My_Array[19448];

Normally if you go to the Debug directory in your CCS workspace, you will find the .map file along with the .out file. You can read the .map file which provides more information on how symbols are allocated. 

chenyuefeng said:

I am sorry I didn't see your answering content after "As".Anything else about your answering?

There is nothing after that. I mistyped. 

thanks for your explanation on .bss !  I think the 'memory allocation' window display accompanied with linkcmd file is similar to the .map file you mentioned.Right?

1、Would you please furtherly explain other questions i raised above in my last reply? e.g. since gotta some problem in memory allocation,why can the program run on ignition ,while once input wheel speed of 4 channels,the CAN message stop, meaning that the program stop running or chip stop working for self protection?  (I tested it with sentinels.The STACK didn't overflow (because the sentinelvalue didn't change at start and end addr.), but the RAM's start and end address sentinel value changed)

2、You mention 19448 bytes of spaces in RAM for .bss.  I would say ,this is the result of compilation based on current program ,with linkcmd setting as below,which is mentioned above before RAM re-allocation into RAM0 and RAM1:

...

.bss : {} > RAM

...

So any problems with this code line for setting ? any optimization suggestions for flexible setting for how much RAM space for .bss and .data?

There probably exists some drawbacks in the memory allocation aspect in the program. Do you have some suggestions in detail, as we lack some experience on this?

chenyuefeng said:

1、Would you please furtherly explain other questions i raised above in my last reply? e.g. since gotta some problem in memory allocation,why can the program run on ignition ,while once input wheel speed of 4 channels,the CAN message stop, meaning that the program stop running or chip stop working for self protection?  (I tested it with sentinels.The STACK didn't overflow (because the sentinelvalue didn't change at start and end addr.), but the RAM's start and end address sentinel value changed)

I'm not clear with your question. Are you saying you are able to load the program and the program will run fine initially and later will crash? The hardware does not know how you have built your project. If the program fits in the flash then it will run initially. Later when the program tries to access a variable that is out of the physical range of RAM then there is no such address and the program will most likely just crash. 

chenyuefeng said:

2、You mention 19448 bytes of spaces in RAM for .bss.  I would say ,this is the result of compilation based on current program ,with linkcmd setting as below,which is mentioned above before RAM re-allocation into RAM0 and RAM1:

...

.bss : {} > RAM

As I mentioned, RAM0 and RAM1 are just alias address for SET and CLEAR. The physical size of onchip RAM is only 16kB. If you exceed this limit, it will not fit. You can declare in the linker file with a RAM that is equal to 100MB or whatever value you want. You are only fooling the linker into thinking there is a lot of RAM and it will just build fine. But once you run the program and the physical RAM is only 16kB and the program will just crash. 

chenyuefeng said:

So any problems with this code line for setting ? any optimization suggestions for flexible setting for how much RAM space for .bss and .data?

There probably exists some drawbacks in the memory allocation aspect in the program. Do you have some suggestions in detail, as we lack some experience on this?

I really have nothing else to offer than for you to look at your program and determine how to reduce the RAM usage. Which part of your code is reserving a large area of RAM? Can you show?

Thanks for replying!

chenyuefeng said:

1、Would you please furtherly explain other questions i raised above in my last reply? e.g. since gotta some problem in memory allocation,why can the program run on ignition ,while once input wheel speed of 4 channels,the CAN message stop, meaning that the program stop running or chip stop working for self protection?  (I tested it with sentinels.The STACK didn't overflow (because the sentinelvalue didn't change at start and end addr.), but the RAM's start and end address sentinel value changed)

I'm not clear with your question. Are you saying you are able to load the program and the program will run fine initially and later will crash? The hardware does not know how you have built your project. If the program fits in the flash then it will run initially. Later when the program tries to access a variable that is out of the physical range of RAM then there is no such address and the program will most likely just crash. 

chenyuefeng:

Yes,I am able to load the program and the program will run fine initially without other input signals(here is 4 Wheel speed).But once the wheel speed signals are input, with speed value up to about 100kph or above, the ECU just stop working with CAN messages stopping transmission. The CAN message can only recover after stopping wheel speed signals input meanwhile ignition OFF and then ON. Once ignition ON and program starts to run again,if the wheel speeds input again up to about 100kph or above, the problem re-occurred(means program crash like you said).

chenyuefeng said:

3、So any problems with this code line for setting ? any optimization suggestions for flexible setting for how much RAM space for .bss and .data?

There probably exists some drawbacks in the memory allocation aspect in the program. Do you have some suggestions in detail, as we lack some experience on this?

Charles Tsai:

I really have nothing else to offer than for you to look at your program and determine how to reduce the RAM usage. Which part of your code is reserving a large area of RAM? Can you show?

Here is the .map file main content for MEMORY CONFIGURATION、SEGMENT ALLOCATION MAP、 RAM SECTION ALLOCATION MAP,maybe you can see which part of the code is reserving a large area of RAM:

As you can see above, most of .data region is already out of range. 

Here are another questions below:

4、But as I mentioned before, Why can the program run initially once ignition ON,but when the wheel speed up to 100kph or so (basically wheel pulses) input to the ECU, the CAN message stops transmission meanwhile ECU stop working?? 

 5、Since the RAM for .data is out of RAM physical range,why does the ECU still work initially??    Shouldn't the ECU fail to start initially?? What is the principle?

6、As I know.current program may be hard to reduce the usage of RAM,if possible from your experience,any other method for reducing the RAM use?

7、All in all,   based on current memory allocation method 、target hardware resources requirement、real hardware RAM resources(16K bytes) in combination ,do you have any suggestions for our program integration optimization?

chenyuefeng said:

4、But as I mentioned before, Why can the program run initially once ignition ON,but when the wheel speed up to 100kph or so (basically wheel pulses) input to the ECU, the CAN message stops transmission meanwhile ECU stop working?? 

 5、Since the RAM for .data is out of RAM physical range,why does the ECU still work initially??    Shouldn't the ECU fail to start initially?? What is the principle?

6、As I know.current program may be hard to reduce the usage of RAM,if possible from your experience,any other method for reducing the RAM use?

7、All in all,   based on current memory allocation method 、target hardware resources requirement、real hardware RAM resources(16K bytes) in combination ,do you have any suggestions for our program integration optimization?

Hi,

  As I have explained, the code may run initially after the program is loaded because it has not used some variables that are out of range yet. During runtime, when your program tries to access a location that is out of range, it may be fetching a mirror/wraparound address or even get trapped in a fault exception. For example, the program during runtime tries to access a location at 16k+0x100. The program may base on the data on this location to jump to a different area of the program or do whatever with it based on your program intention. Since there is no physical memory at 16k+0x100 then the value returned may be just junk or could be the data at location 0x100 which is a wrap-around address. The decoder may just ignore the upper address bits beyond 16kB. It is also very possible the the address decoder generate a bus fault because this is an invalid address. You need to check when your program crashes, where is the CPU program counter. The program counter will give some idea what happens to the CPU. You can also look at the link register to trace back your code what caused the exception.

Thanks again,Sir!

What do you mean by "CPU program counter" and "link register" ??

Would you please show them in the datasheet or user manual or some other ways?

Hi,

  Every CPU will have a PC (program counter) and LR (link register). You can find them in the register browser.

Please also refer to this app note for diagnosing faults if you find out that your code crashes due to a fault exception. This app note was written for a different MCU. However, they use a very similar CPU architecture. Both of them are based on Cortex-M3/M4F. 

Diagnosing Software Faults in Stellaris® Microcontrollers

Hi，

     I have tried your suggestions about getting the LR and PC value while program crash shown as the picture below. Can you help explain the meaning of the value displayed?

Hi,

  As expected, you are getting a bus fault from the address decoder. This is why you are trapped in the _Bus_Fault() ISR. The SP register on your screenshot shows 0x7FFFFFA8. This is an illegal address. As I mentioned several times, your program is trying to access RAM that is not physically available. You can also refer to Cortex-M3 TRM and look for Bus Fault Address Register and the Fault Status register and various other fault related registers. These registers will provide information as to which address caused the fault exception. As I provided last time, this app note is also helpful. Diagnosing Software Faults in Stellaris® Microcontrollers. At the end of day, you need to make sure you do not use more RAM than is available to really solve your problem. 

Sorry,sir,I cannot find the 'Bus Fault Address Register' and its address '0xEEE0ED38' in the doc. 'TMS470M Series Technical Reference Manual (TRM)' and doc. under the download link you shared,in which I also cannot find the Page 8-32 you mentioned in the screenshot you posted. Below is the screenshot of the doc.s you shared both in diagnosing software faults in stellaris microcontrollers and Cortex -M3 Revision r2p0 Technical Reference Manual:

Can you show?

Hi,

chenyuefeng said:

Sorry,sir,I cannot find the 'Bus Fault Address Register' and its address '0xEEE0ED38' in the doc. 'TMS470M Series Technical Reference Manual (TRM)' and doc. 

  The TMS470M TRM does not cover the details for Arm Cortex-M3 core. The Arm Cortex-M3 TRM is provided by Arm which I referred the link. I use an older version of the Arm Cortex-M3 TRM while Arm website has the latest version. Not sure why the latest Arm Cortex-M3 TRM does not have the details for Bus Fault Address register. However, you can the details in ARMv7-M Architecture Reference Manual. 

Hi 

I have tried detect the register Bus Fault Address register:

So is this the problem showing that the fault accuring address?But I can not see the  BFSR register in my debug window,can you show ?

Hi,

  If you look at the CFSR (Configurable Fault Status Register), it consists three subregisters and they are MMFSR, BFSR and UFSR. Refer to the ARMv7-M Architecture Reference Manual I sent last time and also see below. BFSR resides on bit 15:8 of CFSR register. 

You can check if the fault is precise or imprecise. If the fault is imprecise then you cannot rely on the bus fault address register value. A imprecise fault normally are due to a write operation. Normally, the address decode logic has a write buffer in order to improve CPU performance. With the write buffer, the CPU does not have to wait until the write operation is complete before executing the next instruction. In another word, the CPU could be executing several instructions while the write operation is going on in parallel. However, if there is a fault due to that write operation (e.g. writing to an illegal address), the fault becomes imprecise and the CPU cannot remember which instruction caused the write to fault as it has already advanced in its instruction pipeline for new instructions. 

As I mentioned several, I strongly suggest you first resolve your program image issue where it requires more RAM than available. If you can resolve this issue then I hope whatever bus fault issue you have right now or other problem down the road will resolve by itself. For your current issue, I will also suggest you increase the stack size. As I see you r screenshot that your SP is at 0x7FFFFFA8. Your stack should reside from 0x08000000 to 0x08000A00. When I see 0x7FFFFFA8, this is an illegal address. This can lead to a bus fault as this address does not exist in the device's memory map. 

Thanks sir again as usual!

As I am in the debug process,I have notice the register  CFSR you mentioned,in which the bit 15-8 are bus fault status. I saw the bits' value for CFSR are all zeros.   Compared with the value of BFAR, it is strange why they are all zeros within register CFSR.  Then I believe in the registers below I mentioned at last reply:

So they seems to show what happened the same time the program crashes or the CAN message stopped running,that is ,some memory access event unexpectedly happened at the illegal address out of range of physical ???

chenyuefeng said:

some memory access event unexpectedly happened at the illegal address out of range of physical ???

I think so. As I just mentioned, increase the stack size and see if that changes the behavior.