CCS/TMS570LS0714: F021 library for use with TMS570LS0714

Hi Joe,

Sorry about the previous thread getting dropped accidentally.

FMSTAT = 0x30000 does not indicate the error that you mentioned in the previous post. These two bits set in FMSTAT indicate that a read-verify operation was in progress when this operation was suspended. This could happen if the processor gets an interrupt for example, unless it is being explicitly done in software. Most likely your interrupt service routines are in Flash memory.

If not done in software, can you disable interrupts when you try to erase the Flash sector? You can re-enable interrupts once the Flash operation is completed.

Regards, Sunil

Thanks for the response, Sunil.

First, I realize that I placed a typo in the error code in my original response.  The FAPI status received from the flash write API call is code 48 decimal which should be 0x0030 hex.

In the reference manual, section 5.7.21 "Flash Module Status Register (FMSTAT)", indicates bit 5 (0x20) to be INVDAT and bit 4 (0x10) to be CSTAT.

I apologize for that confusion.

Before every flash action we call HalCoGen FreeRTOS function portDISABLE_INTERRUPTS() from os_portmacro.h.

I would like to repeat that this code has been working perfectly for years on the TMS570LS1224, and only has problems on TMS570LS0714.  Is there difference between how 714 would handle such flash commands compared to 1224?

I await your response.

Thanks in advance,
Joe Shidle

Thanks for the clarification, Joe.

The INVDAT flag indicates that the application tried to program a '1' to a bit that is already '0'. Flash memory cells are '0' in programmed state and '1' in erased state. So this flag means that the application tried to program a location that is not erased. Can you check if this is possible within your application?

As for the differences between the LS1224 and LS0714 parts, they are identical with respect to the Flash Module controller for the main Flash array. Your application obviously does have to account for the differences in the Flash and CPU SRAM sizes. Other than that, you can refer to the bootloader examples that QJ has created and made available here: https://git.ti.com/cgit/hercules_examples/hercules_examples/tree/Bootloaders/SafetyMCU_Bootloaders

Regards, Sunil

Sunil;

Thank you for the response.

If you refer to the previous thread conversation with QJ I believe all of your questions have already been answered:

1) I have shown code where I have done an erase check, verified that the sector has been fully erased, and the error still persists.

2) I have - per QJ's suggestion, put an additional erase sector before the first erase check / write, and the error still persists.

3) More importantly, the same flash code we are running on the 1224 which has worked for a few years with no errors is now is running on the 0714 with errors.

4) Even more importantly, stepping through the code via the CCS on-chip debugger the code works on the 0714.

So there does not appear to be an issue with the code as written, unless we are missing something.

We are currently trying to write to flash bank 0 (as shown in the code in the previous thread) so I do not believe it to be an issue with the size of flash on the 0714 versus 1224, though we have made sure to define the correct flash lengths in the sys_link.cmd file.

The main difference between the code that is running on the 1224 (successfully for years without error) and is running on the 0714 (errors when free-running, no errors when stepping through code via CCS debugger) is that the foundation HalCoGen code is obviously different.  We created a new project for the 0714 via HalCoGen and then ported the application code, including flash code, from our 1224 project.

I don't know if this is relevant.

Any further assistance or insight you might have would be greatly appreciated.

Thanks in advance,

Joe Shidle

Hi Joe,

The fact that it works correctly when you single-step through the routine indicates it to be a timing issue. What is the target frequency you are trying to use when programming the Flash? Do you configure the correct number of random read wait (RWAIT) states before you configure the clocks to be at this target frequency?

Regards, Sunil 

Hi Sunil;

Thanks for the response.

In both cases of working 1224 and non-working 0714 we use HalCoGen to set up the Flash subsystem and do no deviate from the out-of-the-box HalCoGen defaults.

For working 1224 and non-working 714 the RWAIT is being set to 3.  Code is identical in both include/system.h

#define TCMFLASH_FRDCNTL_CONFIGVALUE        (0x00000000U | (uint32)((uint32)3U << 8U) | (uint32)((uint32)1U << 4U) |  1U)

For working 1224 and non-working 0714 the GHVSRC registers are set the same in include/system.h

#define SYS_GHVSRC_CONFIGVALUE  ( (uint32)((uint32)SYS_OSC << 24U) \
                                | (uint32)((uint32)SYS_OSC << 16U) \
                                | (uint32)((uint32)SYS_PLL1 << 0U) )

And for both working 1224 and non-working 0714 the HCLK is set to 160MHz in include/system.h

#define HCLK_FREQ    160.000F

This is definitely not something we have fiddled with manually.

I have also thought timing might be an issue, and have put in artificially large wait states (idle NOOP) between lines of code, on the order of several seconds, to simulate stepping through the code, but when running the code automatically (i.e. not using debugger) the 0714 code still fails.

Let me know if there is more detailed information you require on our HalCoGen setup.

Thanks in advance for your advice,

Joe Shidle

Hi Joe,

Can you capture the PLL control registers, the Flash RDCNTL register and the GHVSRC register values just before you are about to execute the Fapi_issueProgrammingCommand function call?

Is the main oscillator in your system 16MHz?

Regards, Sunil

Thanks for the response, Sunil.  I apologize for the delay in responding.

The main oscillator is indeed 16MHz.

I tested our board both running through the debugger and printing out the values so it could be run naturally.  Both results were the same.

Joe,

At this point, I would need a test code that I can execute on my setup to see the issue. I can try running my own code (based on the bootloader example) to erase and program code into the Flash, but would like to follow the sequence you are using.

Joe,

One more thing that you can try is to replace the _copyAPI2RAM_() with a call to memcpy(), as described in this thread: 

Note that there is no explanation (yet) for why this works...

Thanks Joe. I will close this thread for now.