• State TI Thinks Resolved
  • Locked Locked
  • Replies 6 replies
  • Answers 1 answer
  • Subscribers 84 subscribers
  • Views 524 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

F28M35H52C: Data Not being programmed on certain address through FLASH API

Preetham kashyap
Intellectual 915 points
Part Number: F28M35H52C

Guys,

I am back again with another question. 

While trying to update a application software though my Bootloader on M3 side, i encountered a issue with regards to the generated Intel hex format of the application software.  

So with in my Bootloader application i program totally 64 bits or 8 bytes of data at once using  the below API. where data_buffer is the pointer to my array of 8 bytes. 

oReturnCheck = Fapi_issueProgrammingCommand((uint32 *)flash_address , data_buffer, 8, 0, 0, Fapi_AutoEccGeneration);

Every byte of data from the application project generated intel hex file gets programmed fine until i reach the below two line:

 :044DA000200030B906

:204DA40040004000400580004000500040059000400060004005A000400070004005B0001B


When i parse through the first line the address i form is 0x00214DA0 and the data i form is 0x200030B9. Now because i program 8 bytes at time the remaining 4 bytes i write 0xFFFFFFFF and pass data_buffer. This data gets programmed fine. 

But when i arrive at the second line where the address is 0x00214DA4 , i guess because of the ECC check performed on this address in the previous step i will no more be able to override 0xFFFFFFFF with the data i want to write and hence i end up in error state when i verify the flash section. 

Below is the Memory section of my application project. Please note i am starting my application flash section from 0x0020C000.

Can i get some hint on where should i make changes so that i don't end up in such situation ??

Thanks

  • 0
    TI__Expert 6795 points
    Hi Preetham,

    Is it possible for you to vary the buffer size based on the size of the data_buffer? In the first case, it should be 4 right?

    You are filling the address 0x00214DA0 - 0x00214DA8 and going back to 0x00214DA4. Better would be to fill the address based on your need.

    Hope this answer helps.

    Thanks,
    Katta
  • 0 in reply to Rajaravi Krishna Katta
    Intellectual 915 points

    Hi Katta,

    I have not tried what you suggested. But wouldn't this bring back the ECC check problem ?? As i require to program 8 bytes at minimum according to what was confirmed in my last post ?? 

    Now what i did try is using a older version of TI ARM compiler TI v5.2.5 and this issue disappeared. Where as using TI v 15.12.6LTS brings back the issue. 

    Can you confirm if its ok to use v5.2.5 compiler ?? What is different in the older version compared to the latest one. I see some memory padding methodology changes by looking at the change in the behaviour ??

    Thanks

  • 0 in reply to Preetham kashyap
    TI__Expert 6795 points
    Hi Preetham,

    Yes. It brings the ECC check problem. I missed to write you to try using DataOnly option. Anyway, I will check with compiler team regarding it. Please allow additional time.

    Thanks,
    Katta
  • 0 in reply to Rajaravi Krishna Katta
    TI__Expert 6795 points
    Hi Preetham,

    We are still working on this thread.

    Thanks,
    Katta
  • 0 in reply to Rajaravi Krishna Katta
    Intellectual 915 points

    Hi Katta,

    Sure, Please update me once you have a explanation from Compiler team. As i need to update the same to a third party software vendor who provides us the RTOS solution !  

    Thanks

  • 0
    TI__Guru**** 241795 points

    The hex utility output you show ...

    Preetham kashyap said:

     :044DA000200030B906

    :204DA40040004000400580004000500040059000400060004005A000400070004005B0001B

    ... is within specification.  I agree it is odd that there is a record with length 4 that is followed by a record at a contiguous address with length 32.  But that is not a violation of the specification for Intel hex format.

    Preetham kashyap said:
    in my Bootloader application i program totally 64 bits or 8 bytes of data at once

    That appears to be a violation of the specification.  It is best not to make any presumptions about the length of the record you get in Intel hex format.

    All that said, I agree this is inconvenient, and I don't know why it happened.  If you would like, we could file a report against the hex utility.  It would report not an error, but inefficient output.  Note that even if this report results in a change in the hex utility, it is still best for you to modify the program which reads the Intel hex format.

    Thanks and regards,

    -George