Flash Programming Problem with TMX5702016

Markus,

Would you please check if you can connect the debugger to CPU and run some simple code from RAM? You need also to check if all the supplies are correct especially the the supply to flash pump.

Thanks and regards,

Zhaohong

Hi,

yes I actually can debug. That's in fact the reason that I know that the flash programming problem con Core0 already starts with the very first request of the F035 library function Flash_Start_Compact_B(). I have not run that code from RAM, I run that code from FLASH. As already mentioned, Core1 .. Core3 can be programmed without any problem. And so I could download the particular test program to another FLASH core and execute from there.

So Debugging via JTAG works without any problem. FLASH programming of all the Core1..Core3 FLASH sectors worrks without any problem. Just the programming of all Core0 sectors always fails. I do not know the internas of the CPU very well. However, I assume that there is one and only one flash pump that is commonly used for all FLASH cores of the CPU. So all wiring and all power supply seems to be ok.

So from my point of view there are just two possibilites. Either the Core0 FLASH is physically damaged (however, I could hardly believe that as we have the same effect on 60 brand-new boards), or the programming of Core0 and just Core0 is inhibit by some unintended configuration of the chip. The only plausible explanation for such an effect that I could find in the reference manual is the fact, that TI seems to write some configuration data into the TI OTP area that provides some relevant FLASH algorithm configuration:

"The TI OTP sectors contain settings used by the flash state machine for erase and program operations."

That's out of the CPU's reference manual. As there's a TI OTP sector for each FLASH core of the CPU, I could imagine that those settings are stored there separately for each core. So if the content of such an OTP sector is distroyed, possibly the programming on one and only one core might be inhibit.

I cannot imagine how such a TI OTP sector could be distroyed during boundary scan, but who knows. I have tried to compare the content of that TI OTP sector between a fully operational board and a board with the programming problem. However, I cannot read anything within the TI OTP area. Neither on a operational board, nor on the board with the programming bug. Either that piece of FLASH is actually not accesable from application software (however, reference manual states that this sector can be read), or some specific configuration of CPU registers is required to make that memory accessible.

Hi,

I know that it's not possible to erase the same flash bank where the code is currently running on. However, that's not my problem. I do not run my test code from flash bank 0. My test software that tries to erase and program flash runs on bank 1. We have some kind of bootloader located on bank 0 and that bootloader starts fully independent software packages on bank 1 or other memory locations. Due to the fact that the boards with malfunction does not allow to program  that bootloader, I used the debugger to force the execution pointer manually to the start address of the bank 1 software package. I.e. for the debugging session I set the program counter register manually to that 0x0008 xxxx entry point address within Bank 1  of that software package running in Bank 1. This Bank 1 software is in fact used in regular operation too for upgrading the boot loader itself. I.e. the flashing of Bank 0 out of this Bank 1 software works without any problem on an ''operational' hardware. But it fails when trying to compact the flash bank 0 on the boards with the flash programming problem.

However, coming back to my original questions. What's about that TI OTP flash sector. Is the content of this sector actually used by the flash programming state machine as stated within reference manual? Is that stat machine configuration actually separated on a per core base, i.e. is it actually possible that a loss of information in one of those TI OTP sectors inhibits the programming capabilities of a single flash bank only? And if yes, is there any way for me to validate that the content of that TI OTP flash secor is still correct (remember my first request: I cannot read anything from those memory regions, neither via readback option of the programming tools, nor via debugger memory viewer nor via software that tries to read from those addresses). And last but not least, is there a way how the content of that TI OTP section could be destroyed (unintentionally) e.g. by the boundary scan process performed by our manufacturer in context of the final production test?

Regards

Markus

Hello Markus,

To answer your OTP question, the API function setup_state_machine() verifies the TI OTP checksum and if there is an error it will return an error of  FAPI_ERROR_CODE_OTP_CHECKSUM_MISMATCH.

One issue with running Flash code from bank 1 while operating on bank 0 is the vector table.  I would suggest try running your code from bank 0 and program bank 1 or from RAM.

Markus,

In the attached gel file, the memmap() function is commented out. All memory from 0x00000000 to 0xffffffff are visible. You should be able to view TI OTP content from CCS memory window.

3414.tms570ls202x6s.gel

Thanks and regards,

Zhaohong

Hi,

thank’s a lot fort he hint with the function setup_state_machine() as well as fort he configuration file that allows me to inspect the previously invisible memory regions. No I actually can confirm that the flash programming of core 0 fails as TI OTP sector is corrupt. I.e. setup_state_machine() results in ok for core 1, core 2 and core 3 but it results in FAPI_ERROR_CODE_OTP_CHECKSUM_MISMATCH for core 0. So that explains why flash programming is no longer possible on core 0.

Based on the new memory configuration file for CCS I could now find out that the problem is not the data area oft the TI OTP flash. That looks ok. However the ECC area for TI OTP core 0 holds a strange symmetric bit pattern that does per sure not hold valid CRC values that corresponds to the content of the data area.

The content of the TI OTP ECC area for core 0 looks like that:

I could imagine that a boundary scan process might destroy some data on flash. However, for two reasons I’m a bit in doubt whether that’s actually caused by boundary scan.

First of all, the CPU reference manual states that such TI OTP sections can neither be programmed nor erased by customer. So why should a boundary scan be able to invalidate that TI OTP ECC region?

On the other hand, even if it would be possible to re-program that flash region another time, I would expect that you just can program the remaining 1’s down to zero, but per sure not in the other direction. However, with such a limitation the probability to get such a symmetric bit pattern (always two consecutive 32bit words holds the same value!) based on an already programmed flash region is quite low.

So have anyone an idea, how such a strange pattern might have found its way into the TI OTP ECC area? Could you imagine that a boundary scan process results in such a damage and if yes, any idea what might cause such a problem? Or do you know about similar problems indicated by other customers. Is there possibly a delivered charge of such CPU modules that has left TI factory already with corrupt OTP memory?

Regards

Markus

Hi,

in the meantime I've learned about the actual implementation of the ECC mechism and I've learned that the 'strange pattern' is the consequence of the uncomplete encoding of address lines within ECC memory. I have not known that before, so just forget my comments about the content of ECC memory.

I also got some more information from our hardware development department as well from our board manufacturer. It seems that the problem we are running in is in fact derived from a known problem described by:

TMS570LS#29 JTAG Connectivity Can Be Lost

The boundary scan process performed by our manufacturer seems to run into that problem and that probably leads to the defective TI OTP Core 0 area.

So one (hopefully final) question: Is there any way to 'repair' that TI OTP are or any workaround that let flash programming work even with corrupt TI OTP sector (e.g. by using Core 1 OTP data for setting up the flash programming state machine to program Core 0). Or is there no way to fix that problem without replacement of the CPU.

Regards

Markus