Trouble Building and Loading a FreeRTOS IMage for an RM57x

An update. I added somesimple LED blinking code that I already have running on an RM46x error free. When I tried to re-program the RM57x using UniFlash the operation failed. I recovered the RM57x board by loading the Hercules Safety MCU Demo application - I had to attempt the load twice before it succeeded. Once the demo code loaded successfully I went back to UniFlash and programmed my new image - the operation succeeded. Next I tried to attach the CCS debugger. When I attached, the code was stuck in the "resetEntry" of "HL_sys_intvecs.asm". It was stuck under the "undefEntry" label. I assume this is because the debugger didn't reset the RM57x when it attached. For grins I tried re-configuring the debugger to load the image on starting a debug image - I expected it to fail and it did.

Hello:

Could you share your project so we can replicate your issue?

Thank you,

Enrique

I zipped up the whole project.

Thank you for your help,

Ray

4666.HelloWorld_RM57.zip

Hello Ray,

  It seems like the flash loader might have encountered some type of ECC error during program verify. There are holes in the program. I tried to use vfill=0xFFFFFFFF command in the linker cmd file so that the ECC iare calculated ncluding the holes. Below is the modified linker command file. The linker is capable of generating the ECC instead of using the CCS's auto-ECC feature. When I rebuilt the .out using this cmd I'm able load the program image into the flash without errors. Once I load the image, I run the program and able to see the LED blinking. I then tried to reflash a few times using CCS. Each time I reflash I rerun the program. I don't see the problem again. Note that i was able to reproduce your problem originally. Please give a try. 

MEMORY
{
VECTORS (X) : origin=0x00000000 length=0x00000020 fill=0xffffffff
KERNEL (RX) : origin=0x00000020 length=0x00008000 vfill=0xffffffff
FLASH0 (RX) : origin=0x00008020 length=0x001F7FE0 vfill=0xffffffff
FLASH1 (RX) : origin=0x00200000 length=0x00200000 vfill=0xffffffff
STACKS (RW) : origin=0x08000000 length=0x00000800
KRAM (RW) : origin=0x08000800 length=0x00000800
RAM (RW) : origin=(0x08000800+0x00000800) length=(0x0007F800 - 0x00000800)

/* USER CODE BEGIN (2) */
ECC_VEC (R) : origin=0xf0400000 length=0x4 ECC={ input_range=VECTORS }
ECC_KERNEL (R) : origin=0xf0400000 + 0x4 length=0x1000 ECC={ input_range=KERNEL }
ECC_FLA0 (R) : origin=0xf0400000 + 0x1004 length=0x3EFFC ECC={ input_range=FLASH0 }

/* USER CODE END */
}

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

/*----------------------------------------------------------------------------*/
/* Section Configuration */

SECTIONS
{
.intvecs : {} > VECTORS
/* FreeRTOS Kernel in protected region of Flash */
.kernelTEXT : {} > KERNEL
.cinit : {} > KERNEL
.pinit : {} > KERNEL
/* Rest of code to user mode flash region */
.text : {} > FLASH0 | FLASH1
.const : {} > FLASH0 | FLASH1
/* FreeRTOS Kernel data in protected region of RAM */
.kernelBSS : {} > KRAM
.kernelHEAP : {} > RAM
.bss : {} > RAM
.data : {} > RAM

/* USER CODE BEGIN (4) */
/* USER CODE END */
}

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

/*----------------------------------------------------------------------------*/
/* Misc */

/* USER CODE BEGIN (6) */
ECC {
algo_name : address_mask = 0xfffffff8
hamming_mask = R4
parity_mask = 0x0c
mirroring = F021
}
/* USER CODE END */

Charles,

I'm not sure what is different in our development environments or our targets, but your solution had strange results for me. I got the same failure using CCS as before so again I switched to UniFlash. When I tried to program the image using UniFlash I got errors - see the attached file (I had to change the extension to ".txt" so your website would accept it).

Once I got the errors, UniFlash "hung up" for a few minutes, but eventually returned after a few minutes. After it returned I also see the LEDs blinking - indicating that FreeRTOS and my tasks are running.

However, according to UniFlash not all of my image was loaded and the red error LED is continuously illuminated, so something else is wrong. In this scenario I can't debug as CCS cannot load the image.

I'm attaching my linker command file so that you can verify I got it correct.

Thanks for your help in trying to resolve this issue,

Ray

8308.uniflashoutput.txt

5383.HL_sys_link.txt

Hi Ray,

 I'm sorry the suggested solution did not solve your problem. After you changed the linker file, did you uncheck the checkboxes in CCS that will enable the auto-ECC and the 64bit alignment?  Since the .out file after linking already contains the ECC section there is no need to generate ECC again in CCS. I had problem before that if I forget to uncheck the checkboxes the flash loader will somehow get stuck and gives errors.

 With the updated linker Cmd file, do you fail to flash the first time but will work the second time? Or it never works no matter how many times you try? In your original project I will fail to flash the first time after seeing the led already running and blinking. But the second time to flash will work. This is all done in CCS. I didn't try uniflash.

 Can you also tell me that if any projects that you build will have the CCS flash loader error? Or it is only this particular project along with the FRTOS?

Charles,

I tried unchecking the Auto ECC and 64 bit align in the flash programmer in CCS - I got the same failure. I went to UniFlash and it asked me for a start address - I entered 0x0 and it attempted to program. It also failed; here is the output:

[09:15:16] Please enter a valid start address.

[09:15:35] CortexR5: GEL Output: Memory Map Setup for Flash @ Address 0x0

[09:15:35] CortexR5: GEL Output: Memory Map Setup for Flash @ Address 0x0 due to System Reset

[09:15:36] Begin Writing flash memory operation.

[09:15:36] Loading program at 0x0: C:\Users\Rlentz\workspace_v6_0\HelloWorld_RM57\Debug\HelloWorld_RM57.out

[09:15:37] CortexR5: GEL Output: Memory Map Setup for Flash @ Address 0x0 due to System Reset

[09:16:41] ERROR >> CortexR5: Error during Flash verification (Flash algorithm returned error condition). Operation cancelled.

[09:16:41] ERROR >> CortexR5: Flash verification returned error condition. Operation cancelled.

[09:16:42] ERROR >> CortexR5: GEL: File: C:\Users\Rlentz\workspace_v6_0\HelloWorld_RM57\Debug\HelloWorld_RM57.out: Load failed.

[09:16:42] File: C:\Users\Rlentz\workspace_v6_0\HelloWorld_RM57\Debug\HelloWorld_RM57.out: Load failed.

[09:16:42] Operation Writing flash memory returned.

Hi Ray,

  I went back and tried to find out why mine was working after changing the linker command file, there was one extra step I did. I unchecked the "Verify" radio button under the Flash Verification settings". And instead I checked the "None" radio button. Somehow the flash loader ran into some sort of program verify issue and this is something I will need to get our CCS flash loader developer to get involved. Can you try to uncheck the "Verify" radio button and check the "None" and see if it works. If it works this can be a temporary solution to keep you going. When I use the "None" I can load the program image without problem and each time I see the LED blinking. You still need to uncheck the auto-ECC since the linker has already calculated the ECC into the final binary.

 Can you also tell me that if any projects that you build will have the CCS flash loader error? Or it is only this particular project along with the FRTOS? 

Charles,

After I clear the "Verify" radio button and select "none" I am able to program using UniFlash - the red error LED is not illuminated.

I still have the same issue trying to program CCS - the red error LED is illuminated.

I also have an RM46x HDK I use FreeRTOS on and I do not have any of these issues.

I tried to set CCS to only download a symbol table so that I can debug without programming an image. I don't know how to make the program execution pause in "sys_main". I tried setting a breakpoint before starting the debugger, but it didn't work. Can you tell me how to do that? If I can debug, then I can continue with my development using the tools in this way until the issue is resolved.

Thank you for your help,

Ray

Hi Ray,

 I'd like you to be able to use the CCS to program the flash. This way you don't need to go back and forth between Uniflash and CCS debug.  I went back to your original project without the modification of the linker command file. I found that if I flush the cache before flashing the program then it always works. As far as why it is working I'm still investigating it. Please give a try to flush the cache. You can do so by going to Tools->ARM Advance Features and select the "Flush All Caches". Once the caches are flushed, you can reload the program to the flash in CCS. Please let me know if it works for you.

Charles,

I'm a little unsure about how to execute the instructions you provided. The "Tools->ARM Advance Features" selection is only available when the probe (and CCS) is connected to a target. I configured the debugger to download the symbol table only, then connected with the debugger. Once connected, I clicked "Flush All Caches" as you recommended, then re-configured the debugger to program the target. Next, I clicked on the debug icon to initiate a new debug session and CCS tried to program the image to the target - it failed just as it has before.

Ray

Hi Ray,

  Sorry that I try to provide a second solution here which might have confused you. Before today I was trying to provide the solution using linker generated ECC. However, you said it did not work for you in CCS. This is the reason I try to come up with a different solution, not using linker generated ECC but using cache flush.

  First of all, I don't use Uniflash at all in either solution. I do everything in CCS for both solutions. I don't use CCS to only load the symbol but also the program image. Once you are connected to the target and in CCS Debug perspective you will do:

  1. Go to Tools->ARM Advanced Feature and click "Flush the cache". You already  did this.

  2. Earlier I asked you to uncheck the auto-ECC checkbox and uncheck the "align program alignments to 64-bits" and also select the "None" as we already have the linker generated ECC. Now, the second solution I'm providing is not using the linker generated ECC. In this case, you will need to check these checkboxes to select auto-ECC, 64-bit alignment and the Verify radio button. I'm not sure if you have done this step to revert back to the original settings.

  3. Go to  Run->Load->Load Program to load the .out file you have.

  This is supposed to flash your code. It works for me and I'm using the exact same project you provided and running it on the HDK board.

  When you said it didn't work in CCS, is it not working no matter how many times you try or just the first time but the second time will work?

 

Charles,

I think we still have a disconnect. The menu items under "Run->Load->" are "greyed out" until CSS connects to the target. I don't know how to connect to the target without telling the debugger not to load the program.

Here is what I tried:

1. Program an image onto the target using UniFlash,
2. Open CCS and start the debugger telling it to only load the symbol table,
3. Go to "Run->Load->Load Program" (which appears now) and tell it to load the program
   1. CSS erases the flash,
   2. Next it attempts to program the image, but It fails in the same way,
4. After this failure, the flash appears to be erased - I see no evidence of my code running (no blinking LEDs).

I don't know how to proceed from here.

Ray

 

Hi Ray,

 Please go to your target configuration file and right click on the file. Once you right click, you should be able to see the "launch target configuration".  Select the launch target configuration. Once you do this, you will then connect to the target by going to Run->Connect Target in the debug perspective. When you do this you should be connected to the device now.  From here Follow the other steps I gave in the earlier post to flash the program. I can also take some screenshots and post them tomorrow if it is still not clear to you. I have already left office.  These are manual steps to do what the debug will do in one step. The problem with clicking the debug is that you can't change some of the settings I mentioned.  Now I realize why you can't get CCS to work with either solution.

Charles,

Please see the screen capture I've attached. When I right click the target configuration file there is no option to "launch target configuration".

Ray

HI Ray,

  Please go to View and select "Target Configurations" about 5th line from the bottom. Once you have the Target Configuration you should see something like below. When you see the RM57L8xx.ccxml file, right click and you will see the menu where Launch Selected Configuration is one of the options.

Hi Ray,

 I take another screenshot to bring out the Target Configuration tab. See below.

Charles,

I've taken a screen video of what I'm doing, but I can't upload the file here because it is too big. Can you tell me how I can get the file to you? If you view what I'm doing maybe you can spot what I'm doing wrong. I did everything you recommended, but the file still fails to program onto the target.

Thank you for your help,

Ray

 

Ray,

  Is it possible to break up the video clips to several files? In the meantime I will also take a few more screenshots on what I did if necessary. Let me just repeat the steps I took.

1. Go to View and select Target Configurations. You should see the Target Configurations tab in CCS.

2.  Look for the target configuration file. Go to the Target Configurations tab and find the file at Projects->HellWord_RM57->targetConfigs->RM57L8xx.ccxml.

3. Right click the file and select Launch Selected Configuration.

4. In CCS Debug Perspective, go to Run->Connect Target. You should see the target connected. If you go to the Disassembly window you should see your current code. Or if you open a memory broswer window and go the address 0x08000000 you can write some value. 0x08000000 is the start address of the L2SRAM.

5. Go to Tools->On-Chip Flash and make sure you have the Auto ECC Generation, Align program segments to 64-bit and under the Flash Verification settings select the Verify. This step is only necessary if you have them unchecked when I was giving the first solution to use the linker generated ECC.

6. Go to Tools->ARM Advanced Features and click on the "Flush All Caches"

7. Go to Run->Load Program and select the .out file. Please make sure the .out file is the original .out file without the linker generated ECC. Not sure if this the step you missed. The .out file you currently have may be generated using the updated linker command file. So please revert back to your orignal linker command and build the .out again.

8. Run the program and see the LED blinking.

9. Repeat 6-8 again to program your code again.

I use the above steps and it is working for me each time.

Please let me know which one of the above steps is not working for you.

 

Charles,

Please go to ftp://ftp.harris.com, the logon is "anonymous" and the password is rlentz@harris.com. You'll find a video file there named "RM57xIssue.mp4". Please look at this and see if you can spot what I'm doing wrong.

Thank you for your help,

Ray  

Ray,
I went to ftp.harris.com/.../incoming and does not see anything there. It did not ask for login either.
Perhaps we can have a webEX session if that works for you.

Charles,

Sorry, I gave you bad instructions. Please click on this link to get the video file: ftp://ftp.gcsd.harris.com/RM57xTssue.mp4

Thanks for your help,

Ray

Charles,

There is a problem with our anonymous ftp site. I'll post a message when I get it straightened out so that you can view the video file.

Thanks,

Ray

Charles,

Please try this link: ftp://ftp.gcsd.harris.com/RM57xIssue.zip You should be asked for a username and password. The username is "anonymous", the password is rlentz@harris.com. Let me know if you can get the file.

Thanks for your help,

Ray

Hi Ray,

 I'm able to download the video from your ftp site. It didn't even ask me for username and password though.  I'm also sorry that this is a frustrating event for you to go through.

 You did exactly what I told you to do. And it is weird that it didn't work for you.

 I can only spot one difference. When you were showing the ARM Advanced Features, I didn't see the MPU Enabled checkbox checked and neither are the Data Cache Enabled and Instruction Cache Enable. Could you tell me if your device at the moment was already erased by Uniflash. The reason is that if the MPU is not enabled and neither are the caches then doing the cache flush has no use. If they are not enabled then it kind of telling me that the device is currently erased with no code running. Is this true?

  Is it possible for you to first use the Uniflash to have a successful flash program. Once you are successfully running the code and see the LED blinking then follow the steps you take in the video. Please let me know if that will make a difference.

Charles,

You are correct in your assumption that I had previously erased the flash on the target before I made the video. I tried again as you suggested with a target that was already programmed using UniFlash with the program successfully running. I had the same failure. Is it possible that our tools are not the same version?

Thanks for your help,

Ray

Hi Ray,

 I will give my exact versions of various drivers that are installed along with the CCS  tomorrow. I have left office.

HI Ray,

  Here are my installation versions. Please tell me yours especially the DebugServer Flash.

Charles,

There are some differences:

HI Ray, I will install CCS 6.1 and see if I reproduce the problem.

HI Ray,
I can reproduce your problem. I'm working with colleague to understand the problem.

Excellent! Thanks for your help.

Ray

Hi Ray,
Could you please download the earlier CCS version 6.0.1.00040 for now and go through the sames steps that we have gone through yesterday. Please let me know if it works for you. In the meantime I will be in contact with the CCS flash loader developer to resolve the issue. Please go the below link to download 6.0.1.
processors.wiki.ti.com/.../Download_CCS

Charles,

I won't be able to get to this until tomorrow because I have meetings for the rest of the day. I'll let you know what happens.

Ray

Hi Ray,

 Hopefully we are getting closer to resolve the problem.

  There are actually two problems with your project in conjunction with the CCS6.1. This is the reason I was only seeing only one problem when using CCS6.0.1. The first problem we need to solve is the CCS6.1.0 problem. There is an issue with one XML file. I'm attaching the file here. 2514.TMS570xC_RM57_4MB_FlashProperties.xml

 Please copy this file to your CCS installation path. For example, this file is in C:\ti\ccs61\ccsv6\ccs_base\DebugServer\propertyDB\TMS570xC_RM57_4MB_FlashProperties.xml for my installation. You might want to first save a copy of your original file. With this modified XML file, it should remove the error about BlackCheckToggle.

  The next problem is the one that we have been looking at the last few days. When you run your LED blinking program, some code remains in the caches which might have prevented the flash loader from loading new program. The flash loader will normally load itself into the L2RAM and executes from the L2RAM. If there is something still remaining in the cache which also happens to be cache hits to the CPU, the CPU will not be able to execute the flash loader from the L2RAM. Another possibility is that the FreeRTOS has periodic OS call to the CPU and somehow the flash loader is unable to first disable the SWI exception. This is what I suspect and suggest to first flush the caches. For the exact root cause and to confirm if my theory is correct I will still need to work with our flash loader developer who happens to be out of office until next week.

  With the new XML installed , I will suggest that you first exit CCS and invoke CCS again for the new XML to take effect. Once you are in CCS, do exactly the same steps that you did in the video to load your program. I don't think you need to do a cache flush if your device is currently blank. But if you have the LED blinking already running then you will follow the steps in the video. It should work now. Please let me know if otherwise. Also note that this particular problem is unique in the sense that I have tried to load other programs into the flash without any problem and without needing first to do a "all caches flush".

Charles,

I followed your instructions. First I replaced the xml file in the CSS folder. Next I used the steps to manually control the debugger as we've been doing for the last couple of days (that is load the target configuration, connect to the target, flush all caches, and load the program). The first time I did this I was able to program the flash from CCS and start the debugging process. Until now I've not been able to do that so this is progress.

However, once the board was programmed the red error LED illuminated and stayed illuminated. When I started this process, the board was programmed with an image using the ECC generated in the linker command file and UniFlash. I tried to erase and re-program again in CCS, but had the same errors as before. After several tries, I eventually was able to get the flash to erase, but the load process reported failure even though I saw the LEDs blinking as if my program was loaded again (or the erase didn't work).

The bottom line is that I still cannot use CCS to debug. I think you're making progress, but obviously the tools are still not quite right. Please note that when I use your ECC modified linker command file I can repeatedly erase flash and re-program using UniFlash and the red error LED is never illuminated. Something is still not right however, because when I add the UDP/IP stack that I have running on the RM46 board just fine, the RM57 board freezes and the red error LED illuminates.

I appreciate you taking the lead to get others involved to straighten this out. I can continue development on the RM46 board until these issues are worked out for the RM57.

Thanks for your help,

Ray

Hi Ray,

 I was hoping big progress but it is making just small step.

 Did you also try to program the flash in CCS with the linker generated ECC. Make sure that the auto-ECC is disabled and None is chosen for verification. I tried it when i was in office today and it worked for me. I really like you to be able to do everything in CCS rather than going back and forth between CCS and uniflash. Of course, so far we know the uniflash is a reliable solution.

 As far as the red LED,  I went back to the  other post you raised back in Feb, I suggested that you enable cache after you perform the _TI_auto_init as one solution.  The _TI_auto_init is trying to initialize the c/c++ global variables. Since the cache is enabled, it creates cache refill operations when reading these global variables. Each cache line refill is 32 bytes. If one line is not fully initialized with ECC then reading the line will cause bus ECC error and the red LED lit. When you fill the holes in the flash using the linker generated ECC, this problem will not occur.  To remove the error LED I think the best way is to fill all the holes with known ECC rather than just enabling cache after the auto_init. Because you can run into CPU speculative access that can read from a hole location at which time the bus ECC error will be detected again.

Charles,

Following your recommendations I can now repeatedly erase , program the flash and debug my RM57x application all in CCS. I took your advice and reversed the calls to auto init and cache flush, but I still get the constant red error LED illumination. I'm good to go for now until you and your team figure this out. It might be worth noting that when I program my image using UniFlash I do not ger the red error LED illumination. Maybe that piece of information will help you track down the problem. For now, I'm good to go. I plan on trying to add the UDP/IP stack back in today.

THanks for yuor help,

Ray

Hi Ray,

 I'm glad that your problem is mostly resolved.

 About the red LED, can you just check one more time if this is happening only when you connect to the device.  Please do the following.

1. power cycle the device

2. launch target config

3. Connect to the target

 If you immediately see the red LED then go to the ESM register and see if the ESM1.Stat2 register is 0x00000004. If the red LED is caused by CCMR5 compare error then this is a known issue.  This issue is described in the spnz180b errata. The errata number is device#56.

  If this is what is causing your red LED to light up then please do the following. I'm also seeing the red LED and my root cause of the red LED is due to the CCMR5 compare error.

  1. Clear the error flag in Stat2 register by writing a '1' to it.

  2. Reset the nERROR pin by writing 0x5 to the ErrKey register.

  If you have done some program and erase then step 2 will not work. You will replace step 2 by step 3 and step 4 below.

  3. Reset the nERROR pin by first writing 0xA to the ErrKey register.

  4. Again write 0x0 to the ErrKey register.

  It will reset the error pin.

Charles,

Your instructions on the red error LED are correct - I'm seeing the same issue as you are seeing.

I integrated my UDP/IP stack code and I'm trying to execute it on the RM57x. The code is hanging in the HL_emac.c file on line 1474:

while (EMAC_BUF_DESC_EOQ != (EMACSwizzleData(curr_bd->flags_pktlen) & EMAC_BUF_DESC_EOQ))

Apparently, the end of queue (EOQ) flag is not being set in any of the emac's buffer descriptors. I have not modified how the emac is being initialized between the RM46x and the RM57x - I call EMACHWInit from xNetworkInterfaceInitialise

HI Ray,

  Glad that everything is straighten out as far as program/erase and the red LED are concerned.

  Do you mind to post the emac problem as a new thread? This way we can keep track of the relevant issues easier.

  You also have an old thread at the below link that is pretty much the same as the current thread. If you believe your problem is resolved, could you also close the other thread. Thanks.

https://e2e.ti.com/support/microcontrollers/hercules/f/312/t/394975