• State TI Thinks Resolved
  • Locked Locked
  • Replies 5 replies
  • Answers 1 answer
  • Subscribers 82 subscribers
  • Views 527 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: Flash Sector Alignment problems on C28 compiler generated hex file !

Preetham kashyap
Intellectual 915 points
Part Number: F28M35H52C

Hi Guys,

First question:

Previously i faced an issue with alignment of Flash sectors addresses on hex file. Later I was suggested to use ALIGN(4) for all the sections using FLASH memory. But now with a slight change in my C28 blinky application there is a incomplete 64 bit word in one of the stream even after using ALIGN keyword ? I have attached my entire C28 blinky project here. 

The hex file data stream that is incomplete:

:18A26000761F0280A8080006761F0280A806000600069A0100060006A1
:20A26C007622761F01001A2400011A200003761F01061800FFFD1800FFFE761F0100CC0001

And my change is in Lab1_C28.c file. I just increased the uldelay value to 10000000.

Is there anything else i should consider in my .cmd file ?

Second question:

If the variable "uldelay" value is 1000000, then i do not see any incomplete alignment in my hex file. So when i use this hex file to program blinky through my C28 Custom bootloader application surprisingly the LED on the control card blinks at a higher frequency ? How could this be possible ? I have not changed any Flash wait states of blinky application. The same below  project is used for this demonstration too. 

 blinky_c28.tar.gz

  • 0
    TI__Guru* 87105 points
    Preetham,

    Regarding the data that you stream from hex file: Aligning the sections on 64-bit boundary in linker command file guarantees that the section would start on a 64-bit boundary. It does not guarantee that the section would end on a 64-bit boundary. This means that the rest of the 64-bits are not used (correct?). Hence, you can program them assuming all 1s for the unused part of the 64-bit segment. Another way to fill the 64-bits is (so you can stream full 64-bits), to fill the unused memory with all 1s using the fill specifier in the linker cmd file. Hope this helps.

    Regarding the LED blinking: Are you comparing the blinky from RAM vs Flash? And are you saying that Flash is faster? Please clarify.

    Thanks and regards,
    Vamsi
  • 0 in reply to Vamsi Gudivada
    Intellectual 915 points

    Hi Vamsi,

    Vamsi Gudivada said:
    This means that the rest of the 64-bits are not used (correct?).

    Not entirely the 64 bits. Ex In the below stream the address that gets programmed till the end is 0x13A26B. 

    18A26000761F0280A8080006761F0280A806000600069A0100060006A1

    Now the in the below line the address starts at 0x13A26C instead of 0x13A270 ! So with this former address i will get a Program ECC error when i try to program, as in the previous case the FLASH API would have already calculated the ECC for 0x13A26C as well rite ? 

    20A26C007622761F01001A2400011A200003761F01061800FFFD1800FFFE761F0100CC0001

    So my question is why am i getting such pattern even after using ALIGN(4) in my linker file ? 

    Vamsi Gudivada said:
    Hence, you can program them assuming all 1s for the unused part of the 64-bit segment.

    I think this will land me in to the same problem i explained before. 

    Vamsi Gudivada said:
    Another way to fill the 64-bits is (so you can stream full 64-bits), to fill the unused memory with all 1s using the fill specifier in the linker cmd file. Hope this helps.

    This sounds like a interesting option, how exactly can i do this ? As my holes are at 0x13A26C to 0x13A26F ? What i tried is 

    FLASHC      : origin = 0x13A000, length = 0x001F80 , fill = 0xffff //which essential fills every location in this boundary by ffff except the holes location.

    So how can i try this option exactly ? 

    Vamsi Gudivada said:
    Regarding the LED blinking: Are you comparing the blinky from RAM vs Flash? And are you saying that Flash is faster? Please clarify.

    No i am running this project from FLASH, but i see a different behavior when i use InitFlash() vs comment InitFlash() function. If you try and run the project i have attached in the first question you will see what i am trying to convey here. 

    Thanks 

  • 0 in reply to Preetham kashyap
    TI__Guru* 87105 points

    Preetham,

    Ok, got it. Aligning a section on 64-bit boundary ensures that it starts on a 64-bit boundary, as I said. However, with in a section, how different functions/variables get placed depends on compiler/linker. Try using the fill option (the way filled is fine) and see if that works for your case. If not, I can forward this to compiler team and they can give you more insight.

    Regarding blink frequency: I looked at your code but did not run. Note that there will be a difference in Flash execution speed between InitFlash() used vs not used. When you don't use it, Flash waitstates would be at max (default) 0xF - unless some previously executed code changes it. When you use InitFlash(), wait-states will be configured appropriately to give you the best performance as per the system frequency you configure. Also, InitFlash() enables prefetch and data cache. Did you see high frequency when InitFlash() is used? Then that is expected.

    Thanks and regards,
    Vamsi

  • 0 in reply to Vamsi Gudivada
    TI__Guru* 87105 points
    Preetham,

    Do you need help from our compiler team or Is this resolved?

    Thanks and regards,
    Vamsi
  • 0 in reply to Vamsi Gudivada
    TI__Guru* 87105 points
    Preetham,

    I am closing this thread since I did not hear from you in the last two weeks.
    I hope you resolved the issue using the fill option.
    You can open a new post as needed.

    Thanks and regards,
    Vamsi