HDK board D1 red led light when debuging

Yong,

Thank you for using our forum.
I will check your project and will be back to you as soon as possible.

Yong,

I need some information on your project.
Which out file should I use? show 0602 LWIP_03_05_01.out?

What are the external requirement to run your test? apparently some CAN network is necessary.

Thanks,

Sorry for that, the out file should be the shou 0602 LWIP_03_05_01.out.

You just link the can1and can2 on the board, the Ethernet and the miniUSB(the serial port) should be linked as well. The IP address of the board is 0xC0A801A5,you can modify it in the lwip_main.c. The PC's IP address is 0xC0A8010F, port number is 23. You can modify the PC's IP address through the #define PC_IP_ADDR 0xC0A8010F, while the port number directly in the udp_bind, udp_connect and udp_recv.

First, the program will intialize the can and the Ethernet, then if the board recives a char from the serial port( through the serial debugging assistant on PC), it will send data through to the PC through the Ethernet. It will be waiting for the serial data.When I click the keyboard of the PC to send the serial data to the board, the D1 lights.

The can test is just another task, if the data transmit successfully, the 31LED will blinky. If data did not transfer, the other LED will be light. It seems this task do not contribute the problem.

Thanks very much for your help!

Regards,

yong

Hi, Jean-Marc

I want to know if you find out the problem about my project? 

Regards,

yong

Yong,

The Cortex R4 CPU is able to make speculative data access. These accesses, can be done outside of your valid code.
Because your application enables ECC checking on Flash and RAM, it is necessary to initialize the full FLASH on your device.
By default, only the FLASH used by your application is initialized with the correct corresponding ECC.
For the rest of the FLASH, the ECC is erase and not valid.

In order to fix this problem, you have to add in your linker command file the "Fill" option. This option will force the linker to initialize the full Flash region, and so the ECC will be calculated and programmed in the ECC region.

The drawback is now your programing time will increase.

I did this try on your application and the Error Red LED does not switch on anymore.

Here is how your linker command should be defined:

The fill value can be any value.

Please have a try and let me know the result.

Thanks for your suggestion, the Error Red LED does not switch on surely. And the programming time is so much longer than before. 

Why the program do not enter any error handling functions such as the notifications etc? Why the ECC would check the flash area I do not used ever, does the error means that the project is no longer reliable though it happens in the flash outside the scope of use?  Can I go on the project without concerning the error for now until the final project is finished, then, fill the rest of flash?

I wonder if we can find the details about the ECC error  through the ESMSRX, like the error address or the value of it? I'm not understand the details about how the ECC works.Does it work with the main.c at the same time?

In the code, it seems that safety initializations operates once in the sys_startup.c before the main.c operates. Then, the program will be operating the main.c about the application codes all the time. 

Regards,

yong

Thank you for your patiently detailed explanation. I've known the process. I will read the Flash Wrapper section as you suggessted. 

If you found the new option to generate the ECC for the unused part of the flash, please tell me that.

Regards,

yong

Yong,

Good to see that you understand the process.

Concerning this new option in the linker, it is not yet available on our released version of the code generation tools. (In beta version for now)

I've contacted our software group and asked them the schedule to include this new option in our released version.

If you are ok, I will suggest to close this thread for now. You can always open a new one for this particular point.

There is also another significant benefit to filling unused flash memory with a known value. You can use this to trap CPU code execution in case it starts fetching code from a memory location that is not intended. Refer to these earlier posts:

http://e2e.ti.com/support/microcontrollers/hercules/f/312/p/265410/930438.aspx

http://e2e.ti.com/support/microcontrollers/hercules/f/312/p/228184/807467.aspx

Essentially, we recommend using a fill value of 0xEEFF3300. This will cause an "undefined instruction" exception if the CPU executes this instruction in either ARM or Thumb-2 mode.

OK, you can close this thread for now. Thanks for your help again!

Regards,

yong

Thanks for replying, I'll follow your suggestion. It helps a lot.

Regards,

yong

Jean-Marc,

You said "There is a new option to be used with the linker to generate the ECC for the unused part of the flash without having to use the fill option."  "I've contacted our software group and asked them the schedule to include this new option in our released version." 

Any idea when this feature will be released and in which version of CCS it will be in?

Thanks, Charlie Johnston

I have the same problem on my board HDK RM46, The program just work fine, but every time I push S3 and S4, the red Led D1 always blinking, and the console told that I have problem with flash memory,even  on basic code like light up ordinary LED, the problem still happened. I am afraid that it might be hardware problem, but after I read your answer, I am so relieved. The question is still the same, how can I solve my problem? is giving command fill like you said will work? And where I can put the code, is it in sys.main.c?Thank you for your response, I am sorry if my question is so shameful, I am student, and it was my first time studying TI board.

Regards