RM57 Flash Programming Error

Zhaohong,
I discovered at least one problem and have started making progress. Apparently, the FreeRTOS project does not initialize the task stack size and/or the heap size large enough to do anything interesting. I changed the stack size from 128 words to 512 words and I changed the heap size from 8192 words to 16384 words. After amkiing these two changes, the application is running properly. I have a red LED lit that I didn't expect to be lit, but that's a minor issue for now. I believe I've solved my initial problem.

Zhaohong,

I can now run my application - a FreeRTOS app with two tasks running. Each task runs one of the "adapted" Hercules LED demos, then logs a message to a queue for the other task and waits for a message on its own task. A very simple adaptation just to demonstrate the ability to run two tasks and do some minimum inter-task communication. The LED demos run fine, however I still have issues.

First, the red "error" LED on the RM57Lx HDK stays lit all the time when running my application,

Second, I cannot re-flash my application using CCS or Uniflash directly.

What I've done so far is:

First, I can repeatedly re-flash by using the Hercules Demo Application to first restore the demo app, then go back to CCS and start a new debug process. This actually works only on the second attempt with the Hercules Demo app, but it works repeatedly. I know the Hercules Demo App uses Uniflash as well, but the reflash only works from the Hercules Demo app.

Second, I used "WinDiff" to look for differences in the source and header files between my application and the Hercules Demo app. The "license wording" at the top of the files has changed and some macros have been expanded in the FreeRTOS files. There are too many differences for me to efficiently spot any issues. Can you please help debug this problem? Would it help if I zipped up my RM57Lx CCS project and get it to you?

Thanks for your help,

Ray

I couldn't find an explanation for what causes the red error LED light on the RM57Lx HDK to turn on. I may have missed it in the documentation, but I don't know how to start troubleshooting since I don't know what could be wrong. Can you point me to documentation that explains how the red error LED works - that is what drives it and under what conditions it illuminates?

Thank you

Ray

Ray,

I would suggest you to take a look at the ESM status registers to see the type error. I am guessing that the error LED is caused by Flash or RAM ECC errors. You need to make sure that the ECC is set for ENTIRE Flash and RAM. RAM ECC is initialized when RAM is initialized. You need to have your flash image to cover the entire range of Flash (4MB). Cortex R4/R5 uses speculative fetch to minimize the the bottleneck of accessing normal memory. The speculative fetches can go beyond the memory range used by your application.

Thanks and regards,

Zhaohong

Ray,
Please take a look at the below post to see if it matches yours.
e2e.ti.com/.../1287789

Hi Ray,
Sorry the link I sent is an internal link. Can you tell me if you are seeing the Error LED immediately after you connect to the target? If you check the ESM status register does it indicate Group2 channel 2 (CCM-R5 CPU compare error)?

Charles/Zhaohong,
I'm new to the Hercules MCU and I'm not very good at navigating the tools or the specific registers. However, I found that I could export the register values once I connected to the MCU. How can I send the file to you?

Hi Ray,

  Can you find out the values for Stat1, Stat2, Stat3, Stat4...Stat9 registers under the ESM module in the CCS registers window as shown below. You can insert the file when you reply to the post. When you try to reply a post, make sure you click on the "Use rich formatting" at the lower right corner of the text window. You will be able to see the icon to attach file.

Yes, Stat1 is 0x80000000 and the others are all 0x00000000.

7367.Registers.txt

Hi Ray,

  I see below two register values. The Stat2 is for the ESM Group2 error status and it indicates a CCM-R5 CPU Compare Error. This is a known issue. We will publish an updated errata which will include this problem. CCM-R5 is a module whose main function is to constantly compare the outputs between the 2 lockstep CPUs. Whenever this is mismatch, it will signal the ESM module. However, CCM-R5 should not compare the CPU's outputs when in debug mode. A halting debug event can be asynchronous to normal program flow and cause the CPU to lose lockstep. What happens is that in RM57, the CCM-R5 by mistake continues to compare the two CPUs in debug mode. This only happens when you connect to the target the first time. Afterward, there should be no more mismatch detected. What you can do right now is to clear the LED and continue with your application. To clear the LED it depends if you have done any flash programming right after you have connected to the target. Here are the options.

1. If you just power cycle the device and connect to the target the first time and you see the LED, you can clear the LED by writing 0x5 to the ErrKey register in the ESM module.

2. If you power cycle the device and connect to the target but you went ahead to do some flash programming while the LED is ON, then you will clear the LED by first writing 0xA to the ErrKey and then followed by another write of 0x0 to the ErrKey register in the ESM module.

Once you clear the LED it should not turn on unless there is a "real" mismatch between the two CPUs. Also if your target is not connected to the debugger and you simply let the device free run, it should not turn on the LED.

R Esm1_Stat1 0x0000000B 0x80000000
R Esm1_Stat2 0x0000000B 0x00000004

Charles,

I'm not sure I agree with everything in your analysis. I'm not sure how detailed you've followed this thread, but when I use the Hercules Demo software I don't have any issues with errors/faults or the red error LED. When I use the HALCoGen tool to create a project for the RM57Lx using FreeRTOS I have the error/fault issues discussed in this thread with the flash and the red error LED.

I added to the HALCoGen project source code I borrowed from the Hercules Demo code to turn on/off the white LEDs. I used that code to show that I could have two tasks running under FreeRTOS with each doing work (in this case turning on/off the white LEDs). I'm going to try compiling the HALCoGen project without the code I borrowed from the Hercules Demo and see what happens.

Ray

Charles,

I tried the following:

1. Comment out everything in "HL_sys_main.c" in the main routine so that only the OS is created and nothing else happens,
2. Start un-commenting things until I could get a failure.

When I did this I noticed I would get the red LED intermittently - either when I strated to erase flash, or immediately after my application downloaded from the CCS debugger. However, in all cases I was able to use the CCS debugger and erase/re-program flash - something I was not able to do before.

This behavior persisted while I un-commented things:

1. First I uncommented the creation of tasks queues - red LED behaved the same, CSS debug was able to erase/re-program flash,
2. Next I un-commented the creation of the tasks -  red LED behaved the same, CSS debug was able to erase/re-program flash,
3. Finally, I un-commented the start of the FreeROTS scheduler  - red LED behaved the same, CSS debug was not able to erase/re-program flash,

I had to revert to the Hercules Demo application to successfully erase the flash again and recover the RM57Lx HDK board. It appears when I ran the LED demo code I borrowed from the Hercules Demo application I got the "hard" failure that CSS and its debugger could not recover from. That is CSS and the debugger could not erase flash. I find this interesting since it appears that the Hercules Demo application uses uniflash as well to erase the flash. The other curiosity is that the Hercules Demo application fails on the first attempt to erase flash but succeeds the second time repeatedly.

I'm attaching my CSS project file in the case you're inclinded to investigate this behavior. I won't be at work tomorrow (my company has a 9 day 80 hour schedule), but I'll be back Monday morning.

Thanks for all your help to date,

Ray

3377.HelloWorld.zip

 

Hello,

  For some reason I'm not able to rebuild your project. However, I simply load your .out file into the device and I'm able to see the various white LEDs blinking. I also see the red error LED. When I tried to reload the same .out, I will fail with a 'Load failed" msg.

  To continue with the flash programming I do the below steps:

  1. Reset the device. You can do this via the CCS from Run->Reset->System Reset in the Debug perspective

  2. Go to the ESM register in the Registers window

  3. First write a 0xA to the ErrKey register

  4. Second write a 0x0 to the ErrKey register again

  After you perform the above steps you will be able to clear the nERROR. Somehow the flash programming wasn't able to proceed because of the nERROR. Try to reload your code again and I think it should work.

  I suspect the root cause of the problem is in the HL_sys_startup file. I have the code snippet below. The cache is enabled via the _cacheEnable_() is called before the global variable initialization via the __TI_auto_init(). Please try to reverse the order of these two functions by calling __TI_auto_init() before _cacheEnable_(). Please let me know if it makes a difference such as allowing you to program/erase without anymore loading errors.

    _cacheEnable_();

/* USER CODE BEGIN (24) */
/* USER CODE END */


/* USER CODE BEGIN (25) */
/* USER CODE END */

        /* initialize global variable and constructors */
    __TI_auto_init();

 

Charles,

After I modified HL_sys_startup.c as you recommended the RED LED light is not lit during my demo application execution. However, I still have the flash programming error issues. Your instructions for clearing the nERROR cannot be followed as you have written them. The registers can only be written to during an active debug session. Once they are written, the debug session must be exited before the image can be downloaded through CCS or Uniflash directly. When exiting the debug session, the CPU is reset and red LED light re-appears. I can still recover with the Hercules Demo application as I described before.

Once I recover the RM57 using the Hercules Demo application and go back to CCS to re-program my image, the red LED illuminates immediately when the flash programming operation begins, but it clears as soon as my application begins execution. I'm convinced this problem is being caused by something in the HALCoGen generated project. For now, I have a work around and plan to continue with my prototyping effort. However, before I can produce a deliverable application I need this problem to be fixed. Maybe you can engage the FreeRTOS application engineers in this issue.

Thanks for your help,

Ray

Hi Ray,
When I ran your executable, I found the nRROR was due to ECC bus error while the CPU was in the __TI_auto_init() performing global variable initialization. There was a LDR operation at the end from the address 0x1840. There is nothing wrong with the data at this location. It has proper ECC. I think the problem is that the data at this location happens to the last data in the initialization table. When the cache is enabled before __TI_auto_init(), a read from the address 0x1840 will cause the CPU to perform a cache refill of an entire cache line. One cache line is 32 bytes. Other than the data at 0x1840 the remaining bytes are in their erased state including their corresponding ECC checkwords. When the cache refill is performed these erased data are detected as uncorrectable ECC errors. This is the reason that if you reverse the order between enabling the cache and performing global initialization will remove the LED. Anothe way which is actually the recommended way to solve this problem and other potential issues is to intialize the erased regions with their proper ECC checkwords so that the CPU will not detect them as errors. Cortex-R5 has the capability to perform speculative fetch. If the speculative fetch is performed on an erased location without an initialized ECC, you will see the nERROR LED again.

Charles,

I have both an RM46Lx and an RM57Lx HDK. I used HALCoGen to generate a FreeRTOS project for each target platform. The changes I made in both projects are:

1. I changed the task stack size to 256 (from the default 128),
2. I changed the heap size to 16384 (from the default 8192),
3. I set the EMAC address to 0x00 0x08 0xEE 0x03 0xA6 0x6C (as recommended by TI so that I can later integrate LWIP)

I used the exact same led_demo.c file I borrowed from TI and my sys_main.c modified to run two tasks that call methods in the led_demo.c file. This post has been all about the issues I've had with the RM57Lx HDK - flash programming and the red error LED. I've had no issues with the RM46LX - no flash programming issues, no issues with the red error LED.

For this reason, I believe something is not right in the TI support for FreeRTOS in HALCoGen. I'm moving on to try and integrate LWIP.

Thanks for all your help,

Ray