LAUNCHXL-F280049C: FAPI program flash skips address and erase can skip sectors

Hi GI,

Please review this flash API usage FAQ: https://e2e.ti.com/support/microcontrollers/c2000-microcontrollers-group/c2000/f/c2000-microcontrollers-forum/951668/faq-faq-on-flash-api-usage-for-c2000-devices 

We will review your post on this Friday.

Thanks and regards,

Vamsi

FAPI user guide doesn't explain why the next address is correct but there is no data being programmed then it jumps to the next address. So these 4 words 0x0009C0A3 are (FFFF, FFFF, FFFF, FFFF) then it starts writing again. Also the provided 128bit example (Pg.20-21) is a bit crude as it has FAPI error detection in the 4 loop. The 4 loop will break out in case of error and does not need to get FSM status in the 4 loop unless it is polling for FSM Busy condition.

Seemingly program mode is not returning the expected status shown on page 20  (Fapi_Fsm_Ready) 

Hi GI,

Did you already go through the FAQ that I shared?

Thanks and regards,

Vamsi

Hi Vamsi

No but thank you for the FAQ link and just quick review before posting this.

Have discovered problem in FSM program mode timing and 4 loop should not rely on ready status alone. Need to wait on busy status too. There are 156 words to write, verify will just complicate until program is working correctly. Now it only voids 0000 in a few places but is not skipping addresses and the struct member pointer is working much better.

Noting the example it's obvious FSM program mode x49c is running much faster. Now adding 40µs delay macro between busy and ready status in 4 loop.

Hi GI,

Glad it helped.

Regarding voids 0000: Are you saying that API is skipping programming 0000s even if you provide 0000s in your data?

Thanks and regards,

Vamsi

No the FSM is just going nuts, writing far beyond the block size of the current sector and adding 0000 to the first (unsigned int) it comes across after an (int) data type.

Worst of all once FAPI programs sectors other than with FFFF it refuses to erase them and throws illegal interrupt exceptions after POR. Yet FAPI reports success when anything other than success has occurred. Seemingly this FAPI code was never tested on x49c and simply does not work correctly with 100MHz SYSCLK. We need to set the FSM to use a slower clock source divider but I don't find such driverlib function to set FSM clock prescale.

Note the return status is simply wrong, single step F5/F6. Fapi can't run 100MHz clock rate or perhaps the PLL speed is too fast. The MCU must be run 100MHz SYSCLK and a bit slow at that.

Debug is messing with FSM register RWAIT HAL sets 5 waits. Yet after FAPI programs several sectors incorrectly and cannot erase after POR (throws INT exception "illegal instruction") FSM RWAIT defaults 0xF maximum. Debug cannot single step Fapi erase sector as CSTAT register bit is set 1 debug shows success status occurred.

Hi GI,

Why do you think this is a frequency/wait-state issue?  Any specific reason? Please provide more details.

Thanks and regards,

Vamsi

HI Vamsi,

CCS XDS110 5.5Mhz clock can erase all flash sectors that FAPI could not. I tried everything in debug to erase 2 sectors via FAPI erase. Of course FAPI will return all existing blank bytes are erased as he was doing. The proof of FSM timing issue is program skipping flash addresses, stopped after adding check for FSM busy status + 40us delay in the 4 loop. Tried the same stagey with erase and he simply would not get past debug illegal instruction then loops after POR when the sector has actual data to erase. Long as the sectors were/are blank there was/are no problems. 

Later discovered F021 library copied too (.bss) should not exist in LSRAM  read below. 

Hi GI,

Are you executing the flash API from flash or RAM?

Thanks and regards,

Vamsi

Hi Vamsi,

I read over the FAQ and see 200MHz x7 cannot run Fapi, must reduce SYSCLK 100Mhz seems to suggest FSM and or FAPI has clocking limitations. 

Fapi is in RAM  0 register speed 1 optimizations. The code snip with delay added did not work the very next day, program mode would not write anything to flash debug single stepping.

BTW: Error makes no sense (Fapi_Error_AsyncIncorrectDataBufferLength) as the length is fixed at 4 words. How can the input buffer length ever be wrong? Seemingly Fapi program mode code is having instruction decode issues for it to post such an ambiguous error message.

The F021_API_F28004x_FPU32_EABI.lib shows under (.bss) LSRAM0_1 might explain Fapi function calls failing to execute correctly at high instruction decode speed?

Hi GI,

What is the SYSCLK you plan to use for F280049?

Regarding Fapi_Error_AsyncIncorrectDataBufferLength: Can you search for "How many bits can be programmed at a time using Fapi_issueProgrammingCommand()?" in the flash API usage FAQ?

Thanks and regards,
Vamsi

SYSCLK=100Mhz, 64 bits has been established.

This issue seems related to the program data type assigned as pu16DataBuffer. It does not handle (int) very well which is being used in SDK for motor controls along with floats & longs attempting input as converted data type to unsigned pu16DataBuffer. Seemingly that pu16DataBuffer needs to be a non-specific dynamic pointer without any signs. So program mode simply uses whatever data type dumps into a benign untyped program buffer.

If it is just a data buffer pointer why does program mode via pu16DataBuffer not allow program mode via int16t datatype F012.h defined? Oddly data buffer allowed float32_t with 2 words 64 bits but was skipping word addresses. Seems FAPI needs an extensive review to handle C2000/ARM data types more efficiently. Perhaps why the FSM is having issues at higher SYSCLK speeds, 100MHz and greater.  

Compiler data types:

int, signed int, 16 bits Binary -32768 to 32767

FAPI program mode: unsigned int 16 bits Binary 0 to 65535

Hi GI,

1) Let us first close the SYSCLK issue:  Why would you configure SYSCLK for > 100MHz?  Device supports only up to 100MHz.

2) Since you said illegal trap occurred when you use 4 wait-states at 100MHz: What is the clock source you are using? INTOSC2 or external?

Thanks and regards,
Vamsi