[ABANDONED] OpenFlashLoader fails to write/verify encrypted application binary

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

  • [ABANDONED] OpenFlashLoader fails to write/verify encrypted application binary

    Hi there,

    I modified the OpenFlashLoader so that he encrypts the given application binary and writes it to the QSPI attached flash memory.
    When I run the OpenFlashLoader using JFlash via "Programm & Verify" it works out fine, the application is flashed and verified successfully, although the overall operation is quite slow.
    The problem though is, when the same OpenFlashLoader is used by any other tool then JFlash, e.g. the Ozone debugger, the flashing process fails in a quite early stage, saying "Verify failed...".

    My theory is, that it works with JFlash, because JFlash is rewriting and verifying the complete flash from beginning to end. On the other hand Ozone seems to have some logic when writing/verifying in that respect, that he does not have to write/verify each and every flash page, which then causes problems on verify because the flash content is encrypted (but I'm not sure).

    My questions are:
    • do you have an explanation, why it works with JFlash but not with Ozone?
    • do you see any possibilities to configure Ozone or the OpenFlashLoader in a way, that downloading the application to the target device works also with the OpenFlashLoader writing the application encrypted?


    Help and tips are much appreciated, thanks in advance
    Best regards
    Paul

  • Hello Paul,

    Thank you for your inquiry.
    Please note that the open flash loader interface is provided without support so we can offer only guidelines.

    Could you provide your J-Flash project file for reference? Do you do a chip erase there before programming?
    If yes, try issuing a chip erase before download in Ozone. How is explained in Ozone manual.
    What about the encrypted data in QSPI. Is this modified by your application or does it stay encrypted in QSPI?

    Regarding the overall operation speed, the open flash loader interface uses the same internals like our internal flash loaders which are unmatched in speed by competitors and run usually at the technical limit of the target flash controller.
    So if the programming operation is unreasonably slow it can have three reasons:
    1. Target interface is to slow. Try to increase that.
    2. Target flash controller is clocked slowly.
    3. Your routines implemented via open flash loader interface waste time somewhere. Try not to use library functions and implement the callbacks as low level as possible.
    (4.) The targets flash controller is actually that slow, consult the technical specification sheet for that.

    Best regards,
    Nino
    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.