• State Resolved
  • Locked Locked
  • Replies 6 replies
  • Answers 2 answers
  • Subscribers 29 subscribers
  • Views 699 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.

F021 flash API options on RM46L852

Niels Groving
Prodigy 60 points
Other Parts Discussed in Thread: HALCOGEN, RM46L852

We're trying to implement a small (<12KB) bootloader for the RM46L852 using HalCoGen 4.03 with the GCC toolchain.

The standard HalcoGen UART project (that can print text strings via the UART) is used as a base, and then we call the F021 flash API as described in the F021 documentation PDF.

The application is flashed to address 0. In main() it copies itself to the top 16KB of RAM via assembly code called from main(), and jumps to that position and continues execution (absolute jump from instruction in flash to the 'following' instruction in RAM, without reset)..

Everything up to the call to main is unmodified HalCoGen code.

We can print via UART and also successfully execute erase and program operations on FlashBank7 - running from RAM at 192MHz. Printing the value of the PC also confirms running from RAM.

BUT... when we change to use FlashBank0, the call to Fapi_setActiveFlashBank(Fapi_FlashBank0) never returns...!

We have also tried to run at 180 MHZ and even lower, with no change. (Can the FAPI run at 192MHz?)

Disassembling the .ELF file to see the Fapi_xxx functions seems to indicate that the code is relocated correctly, so function calls/jumps are relative and accesses to RAM variables are in the 0x8000000 + stacks area.

What can cause Fapi_setActiveFlashBank(Fapi_FlashBank0) to fail ?

Is this way of using HalcoGen + Fapi simply not possible for some reason?

Kind Regards

Niels G.

  • 0
    TI__Genius 11645 points
    Hello Niels,

    With what you have explained above, I see you have ported the code to run from Ram w/o any issues since you are able to erase Bank-7 successfully.

    Before moving to bank-0 are you setting the Flash wait states properly ?

    Please let us know.
  • 0 in reply to KARTHIKEYAN RAJAMANICKAM
    Prodigy 60 points

    Hello Karthikeyan,

    Thanks for  moving attention to this.

    We let HalCoGen set the wait states automatically to 3 + 1 based on the 180 or 192 MHz frequency, which generates the below code in system.c:

        /** - Setup flash read mode, address wait states and data wait states */
        flashWREG->FRDCNTL =  0x00000000U
                           | (uint32)((uint32)3U << 8U)
                           | (uint32)((uint32)1U << 4U)
                           |  1U;

    We do not change it afterwards - would we need to do this at any time, if so when ?

    Perhaps the MCU changes it by itself during some operation, or in one or more of the Fapi_xx calls ?

    We have tried both Pipeline and Normal flash mode, none seem to work with bank-0..

  • 0 in reply to Niels Groving
    TI__Genius 11645 points

    Hello Niels,

    Your wait state settings look correct to me and MCU does not change the WS by itself :) nor there are any in the API which does that.

    Now that the only thing I can think off is that there is something still lying in the flash which is used by your code running out of ram, which I guess is keeping your flash state machine busy for Bank-0. If that's the case then Flash API checks for the bank-0 to be idle and if not then it just waits there.

    Can you please recheck your code once again to make sure there is nothing lying in flash bank-0 that your code will be using while running the flash api's ?

  • 0 in reply to KARTHIKEYAN RAJAMANICKAM
    TI__Genius 11645 points
    Hello Niels,

    Did you manage to solve the issue ?
  • 0 in reply to KARTHIKEYAN RAJAMANICKAM
    Prodigy 60 points
    YES -we think we got it solved yesterday!

    We found it to be an issue with the CopyToRAM code, where the assembler generated a wrong address value constructed from a combination of several literal constants and addresses - possibly because the address was only later fixed up by the linker..
    Not quite sure, but happy for the time being - flashing af 192 MHz.

    Thanks for your support.

    Kind Regards
    Niels
  • 0 in reply to Niels Groving
    TI__Genius 11645 points
    Thanks for confirming that. Can you then pls click on verify answer and close this thread ?