Very inefficient flash writing process (on RT1170)

This site uses cookies. By continuing to browse this site, you are agreeing to our Cookie Policy.

  • Very inefficient flash writing process (on RT1170)

    Hello,
    I traced the process of writing a FW in flash using a logic state analyzer. I was able to observe some very questionable behaviors.


    The file is quite large, and even its decoding contains more than 3,000 commands. However, there are some peculiarities that I would like to discuss with you


    Reads take place byte by byte
    I was able to observe that the memory reads, in the initial comparison and in the final verification are done using the 0x6B command, but one byte at a time. In this way, reading 1kB takes 40960 clock cycles. Whereas on the other hand if I read the same kB in one transaction it would take 2086 clock cycles!!! That's a 95% reduction in time!!!!
    Why do you read one byte at a time?


    QE bit is written and rewritten many times (for no reason at all)
    In the track I took the QE bit is written and rewritten a total of 79 times. Very often between two consecutive writes (one 0 and the other 1 or vice versa) there are no other operations, making the write completely useless. Also Even if QE bit is 1 the "normal" commands still work, so there is no need to rewrite QE to 0 for the Page Program or Block Erase commands.


    At the end QE bit remains at 0
    The rom bootloader requires the QE bit to be 1 in the flash. But the last write done leaves the QE bit at 0, so after a flash write the FW will still not be executable until we rewrite the QE bit to 1 using another FW (residing in RAM)


    The value of dummy cycles is never read

    The memory I'm using right now is an Infineon S25FL064L (ID 01 60 17). It has the setting of the number of dummy cycles in the config3 register. The command to read that data is 0x33. This command is never sent to the flash, so how does the FW know how many dummy cycles to add to the readings?


    The number of bytes of the address is not read.
    The flash can use 3 or 4 bytes of address. setting is contained in the Config2 register, which can be read with the 0x15 command. But that command is never sent to the flash.

    64kB blocks are deleted
    Deletions are made by 64kB blocks. Wouldn't it be more efficient to do it by 4kB sectors (supported by flashes with the 0x20 command)? This would have a finer grain at the cost of a little more time to erase, which is possible to recover by doing better reads



    I know that a FW is injected inside the micro that is used to perform the actual operations (FlaxSPI programming, reads, writes, etc.). Is it possible to get the source code of such FW?

    Let me know if you want the trace (in sigrok format) and how you can share it


    best regards

    Max
  • Hello,


    mastupristi wrote:

    Reads take place byte by byte
    I took a quick look at the sources of our flashloader and did not see any issues that could lead to this.

    mastupristi wrote:

    At the end QE bit remains at 0
    Our flashloaders restore the previous state of the MCU, so if the QE was set to 0 before the J-Link operation, it is set back to 0 afterward.

    Regarding the dummy cycles and address bytes, the J-Link will use the factory default.

    mastupristi wrote:

    Is it possible to get the source code of such FW?
    Yes, it is possible to purchase the source of our flashloaders. For more information, please create a ticket at our support page.

    To investigate this issue further, could you please create a ticket? This makes it easier to keep track of such issues:
    segger.com/support/technical-support/

    Best regards,
    Simon
    Please read the forum rules before posting.

    Keep in mind, this is *not* a support forum.
    Our engineers will try to answer your questions between their projects if possible but this can be delayed by longer periods of time.
    Should you be entitled to support you can contact us via our support system: segger.com/ticket/

    Or you can contact us via e-mail.