Cart New Account Login

HomeAbout usProductsSupportForumsBlogCustomer Service

Please accept the use of cookies on our site

At PEmicro we use web browser cookies in order to provide you with an enhanced experience and in order to be able to do things like shopping cart processing and identify you when you login to our website.

Click here to accept

search inside this forum
search inside all forums
Cyclone for ARM, SAP, s-flash verification probs (VM command, $5003 error)
Jon G. Aug 18, 2015 at 10:36 AM (10:36 hours)
Staff: Edison T.

  • Configuration:

    CYCLONE for ARM, v1.61-0.7
    Kinetis MKM14Z128CHH5
    MX25L8006E s-flash
    Tried and tested algorithm (see forum postings passim)
    Cyclone Image Creation Utility

    I'm using Image Creation to create a SAP file and .cfg to program external s-flash. The flash part is an 8Mb unit. The .s19 file programs it from address 0xe0000, but we have had the same problem programming from 0x000000.

    The problem is this:

    1. We create a config that loads the algorithm (CM) and object (SS), then erases module (EM), programs module (PM), and then verifies module (VM) -- see later -- and download this to the CYCLONE.

    2. The CYCLONE goes through the whole programming procedure according to the SAP file downloaded to it, but fails at the VM stage with error $5003 ("Verification operation failed or canceled").

    3. We can use upload module (UM) to read the entire contents of the s-flash to a file. This file contains exactly what we attempted to program: an entire device full of 0xFF, except for the ROM image in the .s19 file. When we compare the binary contents corresponding to the .s19 file with those uploaded from the s-flash, these correspond byte-for-byte, so we believe the s-flash was programmed correctly.

    Hence, we believe the VM error is a false positive, but we don't understand why this should be.

    I know that in the manual it says that programming s-flash is self-verifying, but we have had examples where not all the area was programmed: there were 0xFF blocks where there shouldn't have been, so clearly the programming went awry in places in that case; perhaps a SPI timing issue? This is why we wanted an additional, deliberate VM step at the end, to validate the programming.

    I note that a similar problem was reported in - however, that was directly programming the MCU, not programming s-flash.

    Advice, or similar experiences, would be welcome.




    • I should clarify: we use Cyclone Image Creation for all of the above, apart from the manually-run UM command afterwards.

  • Greetings,

    I am sorry that no one answered your question on the forums. Is this still an issue? Let us know and I will make contact the best person to answer your questions.

    Takao Yamada

Add comment

   Want to comment? Please login or create a new PEMicro account.

© 2018 P&E Microcomputer Systems Inc.
Website Terms of Use and Sales Agreement