TMS320F28388D: RE: TMS320F28388D: CPU1 gets stuck after power on

Hi Shawn,

We will review and get back to you in couple of days.

Thanks and regards,

Vamsi

Hi Shawn,

Did you inspect what part of the application is mapped to that address location?  And when it gets executed?  

Can you enable ECC check and read the entire flash (this code that reads the flash should be in RAM) and see if there are ECC errors?  

Thanks and regards,
Vamsi

Hi Vamsi,

Thank you for your reply.

For your questions:

Did you inspect what part of the application is mapped to that address location? And when it gets executed?

1. This section holds the library function "memset()";

2. "memset" is called several times during application initialization, and when ITRAP is triggered, it is not the first time memset is called. Therefore, I don't think there is a problem in this FLASH area, but other factors lead to something abnormal when fetching instructions, because I once tried to change "memset" into a for loop, there is also a probability of abnormal.

Can you enable ECC check and read the entire flash (this code that reads the flash should be in RAM) and see if there are ECC errors?

1. About ECC check you said, do you mean that I add some check functions to be performed by RAM, and check the ECC of the whole FLASH after the system is started?

2. One thing to note is that even if I don't re-write FLASH and just power off and restart it, there is a chance that the application will work. If the ECC of FLASH is faulty, should it always fail to launch?

Thanks and regards,
Shawn

Hi Shawn,

Thank you.  

Please note: I am out of office for the next 4 days. 

I will be able to review and get back to you by the end of the week.

Regards,
Vamsi

Hi Shawn,

1. Is memset() mapped to flash for load and RAM for execution?  If yes, can you check whether the RAM content is intact when you notice the ITRAP?

2. What are the SYSCLK and flash wait state configurations used in your application?

3. It may not be a ECC issue then.  It might be a RAM corruption during the application execution.  However, yes, I would suggest to check the validity of the ECC of the entire Flash by executing a simple code from RAM (for this debug purpose).  

Thanks and regards,
Vamsi

Hi Vamsi,

Thank you for your reply.

For your questions:

1. Is memset() mapped to flash for load and RAM for execution?  If yes, can you check whether the RAM content is intact when you notice the ITRAP?

The memset() function is executed directly from FLASH and is not assigned to RAM. 

2. What are the SYSCLK and flash wait state configurations used in your application?

The sysclk is 200MHz, and FRDCNTL.RWAIT = 0x03.

3. It may not be a ECC issue then.  It might be a RAM corruption during the application execution.

Could you please explain RAM corruption further？

Thanks and regards,

Shawn

Hi Shawn,

Some causes of RAM corruption are when a stack overflow occurs, a memory leak happens, or when there are uninitialized variables being used. Do you have any warnings associated with the bootloader or application code?

Thanks,

Charles

Hi, Charles,

Thank you very much for your reply. In addition to software, are there hardware or external factors that may cause these phenomena? Because the anomaly is concentrated in a few boards, other boards do not have this problem. Also, when I used the faulty circuit board to restart repeatedly, I only had the chance to enter ITRAP. Most of the time, it started normally, so it doesn't seem like a pure software problem.

Thanks and regards

Shawn

Hi Shawn,

I'm not sure about hardware/external factors for the devices, I'll have to pull some other experts in on this. Will get back to you within the next day.

Thanks,

Charles

Hi Shawn,

Since we did not hear back from you in the last 3 weeks, I am assuming that this issue is resolved.

I am closing this post.  Please open a new one if you have further questions.

Thanks and regards,
Vamsi