LAUNCHXL-F280049C: FAPI program floating point

Hi GI,

We will review and get back to you mid next week.  Thank you.

Regards,

Vamsi

Hi Vamsi,

Working Sunday shows a real dedication to TI. I found below layout of floating-point integer structure may help. 

Hi GI,

Thank you for the info.  

Will review and get back to you mid next week.

Regards,
Vamsi

Hi GI,

Are you not able to provide the 32-bit format (you mentioned above) in the parameter to the flash API program function?  

Please note: I am out of office and will be back to office mid next week.  Please expect delays in my replies.

Thanks and regards,
Vamsi

HI Vamsi,

Yes the float32_t is the format for the first variable (24.0) to program into flash sector, seems to void pu16DataBuffer with 0x00. Yet the full extent of the casting buffer is 310 length, not simply 1 float32_t variable. The FAPI buffer length error message shown in the other thread does not seem to make sense in this regard. Though the C2000 compiler float is a double word 32bits wide so the pu16DataBuffer is not wide enough requires simple FAPI program rewrite to assist doubles.

Edit: COF float is a double word or 32 bits and eabi double is 64 bits so float is still 32 bits.

(2) It is recommended that 32-bit floating point values for COFF be declared as float, not as double.

Hi GI,

I mean to say: Are you not able to convert the float to the format that the flash API can accept?  Whether it is float or any other data type, as you know, eventually it is going to reside in the memory as 0s or 1s.  

Thanks and regards,
Vamsi

Vamsi Gudivada said:

I mean to say: Are you not able to convert the float to the format that the flash API can accept? 

We can't fit 32bit word into 16bit defined buffer. That simply can't ever work unless the compiler magically splits 32bit float into two 16bit words. Then the buffer sizeof would double and take twice the flash memory space. Not a good solution the FAPI must be rewritten to handle 32bit words there is no way around that data buffer restriction.

Edit: Since the TMS320C28x char is 16 bits (to make it separately addressable), a byte is also 16 bits. This yields results you may not expect; for example, size of (int) = = 1 (not 2).

This is not a firmware upload or that would be a solution. These are 32bit floating point variables and must be stored as 32 bits since retrieving a 32bit DWORD as 2x16bit words requires special ASM intrinsic function handling, more than I ever would consider for this issue.

If the *pu16DataBuffer is only a pointer to a 32bit flash data word, then it should be working with (float32 *) pointer I recently added. It may be the (sizeof) needs to be divided by 2 as the edits above imply C2000 compiler returns 1 for 16bit word, should return 2 for float32. Hence I didn't physically count the number of parameters and relied on ((sizeof) userParams)) to determine the buffer space needed for FAPI data words.

No need to reply if it works will make thread green.

Hi Vamsi,

I see you reply to other post 19 hours ago and FAPI has storage issues not being fully explained in PDF. 

1. There is no documented context that explicitly explains program mode function delimiters such as the start address must be incremented every 4 words. Most anyone logically would assume that sequence is automated since the word automated is used over and over in the PDF.

Example of FAPI inconsistency: Sector erase only requires the start address and automatically increments 16bit address. Program mode start address stops after the first 64bit write thus makes F5/F6 debugging an EXTREEMLY slow process.  

2. There is no documented context that explains program mode function delimiters buffer length must be incremented every 4 words. So text briefly goes on to give some program mode analysis. Yet being well after the fact of explaining program mode delimiters at the top of the subject matter. Add a note or something leave a few bread crumbs as to read further on. I speed read as so much information in TI documents easy to miss elaborated text where it is not expected.

3. There are no bytes being stored via pu16DataBuffer when uint16_t or float32_t  data types cast 64 bits to pu16DataBuffer. 

4. FAPI program mode data buffer name is ambiguous, should be named (*64WriteBuffer) and not pu16DataBuffer. Typically points to 64bit flash aligned CMD sections in most all projects except when 128bit OP write aligned sections are being cast flash data. Keep it simple don't complicate the task, KISS.

5. FAPI program mode does not sequentially load data buffer via the data pointer. Nor handle global typedef struct variables pointer via (float32_t *) &MyStructTag. C2000 compiler does not circulate or do indirect casts of global struct variables in listed format after the first 64bit write to flash. Program mode simply copies the (float32 *) contents multiple times to the end of any 4 loops total buffer (sizeof) divided by 2. Briefly the data pointer is not circular in the global struct list after the first 64bit write. Tivaware (flash.c) reads *buffer contents via pointer, no need to increment index or pointer to buffer via 4 loop, hence FAPI seems overly complicated. 

Hi GI,

Thank you for the feedback.

Regarding your comment saying "I see you reply to other post 19 hours ago": I got little time during my time out and thought of helping as possible.  Hence, checked the E2E's open posts.  Your post did not show up as OPEN since you clicked on the "Resolved" button - when you do this, it won't show up as OPEN post for us.  Hence did not reply to you.  Now, when you replied again, the post status became OPEN.

Regarding your feedback: I can review it when I am back to the office.  Most probably, I may suggest a meeting to discuss your feedback.

Thanks and regards,
Vamsi

Hi Vamsi,

That is unexpected just like the FAPI issues that seem to come up after attempting to program float32_t in 2 loop steps 64bit write. The example seems to be using OTP 128bit alignment, hence Index+8 and 8Word length. Though I am using F021_F32.lib in LSRAM.

The part that makes no sense, text states FAPI writes 64 bits one time only. Yet that is ambiguous since 4 loop must load pc16DataBuffer 8 times 128bit write. In case of storing a float, 4 loop must 2 times to load (float32_t)pc16DataBuffer to write 64 bits?

Seems the index pointer to a 32 bit struct member must step 1 time each pass 4 loop. A float is a different data type requires FPU to decode the read data stored in the exponent field and place precision via decimal point. Oddly the ECC data being written is the same as data only mode, FAPI or FSM skips flash words as it sequences down the index of struct members with different data types other than float. FAPI went nuts wrote data in other sectors way beyond the total word count (155) of 4 loop. 

Opened new thread for erase issue: 

Hi GI,

I am moving your below question on floating point from https://e2e.ti.com/support/microcontrollers/c2000-microcontrollers-group/c2000/f/c2000-microcontrollers-forum/1195860/launchxl-f280049c-all-flash-registers-are-0x0-after-_c_int00 to his post.  This it to avoid mix-up of different questions.

Hi Vamsi,

Does TI have FAPI program source so we can try to fix the f32 lib as to accept floating point input buffer? FAPI may have been written IDE other than CCS since debugging can't locate prometheus.h or some name like that.

Still wondering why (F021_API_F28004x_FPU32_EABI.lib) but no support files for programing flash sectors float32_t puBuffer? So I changed the F021.h input and the float data is there but not accepted by FAPI. Yet the compiler is not converting float due to short length, most likely. There are 310 words in the struct reference of that stored data of userParams. So it's hard to know if floating point data or DCSM is causing issues.

/* Programming Commands */
#if defined(_C28X)
                   extern Fapi_StatusType Fapi_issueProgrammingCommand(
                                                                                                    uint32 *pu32StartAddress,
                                                                                                    float32_t *pu16DataBuffer,
                                                                                                    uint16 u16DataBufferSizeInWords,
                                                                                                    uint16 *pu16EccBuffer,
                                                                                                    uint16 u16EccBufferSizeInBytes,
                                                                                                    Fapi_FlashProgrammingCommandsType oMode
                                                                                                                                                                                  );

We can discuss this here.

Thanks and regards,
Vamsi

Hi Vamsi

Please close this post as the problem of the input buffer datatype was the FSM not programming, thus status of incorrect buffer length. Also had expected FAPI to move input DataBuffer pointer by design as does Tivaware (flash.c). Hence some confusion FAPI can only write 64 bits in one FSM write cycle of program mode, if FSM was actually enabled after POR that is. 

Hi GI,

Ok, I will close this post.

Thanks and regards,

Vamsi