TMS570LC4357: On-chip flash erasing problem

Ben Qin

Part Number: TMS570LC4357

Hi Team,

There's an issue from the customer need your help:

I use the F021 api to erase and write the on-chip flash. The process is as follows:

Erase bank1 - write 0xaa to bank1 - read bank1 space and check whether all is written as 0xaa - erase bank1 - write 0x55 to bank1 - read bank1 space and check whether all is written as 0x55

In the above process, the first erasure, writing, and reading are all normal; the second erasure, writing is normal, and no error is reported, but when reading, it is found that a part of the space has not been written as 0x55, and is still 0xaa

The above problem does not occur for bank7

If I do not call CacheEnable during the startup phase, the above problem disappears;

If I call CacheEnable during the startup phase and call _dCacheInvalidate_ after each flash writing , I find through serial port printing that after the function calling _dCacheInvalidate_ is executed, it cannot continue to execute;

What may be the reason for this situation? How should I solve it?

In addition, what kind of permissions should I configure when configuring the space where flash bank0/1/7 is located in the mpu module?

Thanks & Regards,

Ben

over 2 years ago

0 Ben Qin over 2 years ago

TI__Intellectual 2690 points

Just to add, when I write to bank0 (write the last sector), I will have the same problem as bank1.

0 jagadish gundavarapu over 2 years ago in reply to Ben Qin

TI__Guru 70681 points

Hi Ben,

Can i get a sample project with the issue you are mentioning, this would helpful me to trigger the issue at my end and do the necessary debugging at my end.

Thanks & regards,
Jagadish.

0 Ben Qin over 2 years ago in reply to jagadish gundavarapu

TI__Intellectual 2690 points

Hi Jagadish,

Unfortunately, due to information security involved, we cannot provide the project.

I describe today's progress, the _dCacheInvalidate_ function provided by TI itself is to invalidate the entire cache, and I re-implemented the interface for invalidating according to the cacheline granularity according to the r5 manual (MCR P15, #0, R0, C7, C6, #1), Invalidate the cacheline where the address is changed after each write to flash, which solves the problem of the second read error I mentioned

Although the problem no longer occurs, we are not very clear about the cause of the problem, so we would like to ask the following two questions:

1. Why does the last written data remain in the cache without flushing? Our MPU configuration for BANK0/1 is NORMAL_OIWTNOWA_NONSHARED

Our conjecture is: the first erase and write is done through the API, without going through the cache, the read is read directly through the address, and the cache will cache the data read for the first time; The second erase write also does not go through the cache, but on the second read, part of the data read is actually the first data cached in the cache

2. Why does calling _dCacheInvalidate_ cause the program to hang up and cannot continue execution? Is it related to the fact that SRAM space is configured by the MPU to write_back attribute?

Best Regards,

Ben