Can't Flash Spansion S29NS128P, 0x5554 vs 0x0554 issue.

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

  • Can't Flash Spansion S29NS128P, 0x5554 vs 0x0554 issue.

    I can’t get the Flasher ARM to program Spansion S29NS128P NOR.
    If I manually set the NOR programming sequence by entering the commands in the CPU tab of the project setting window everything works as expected. When I let J-Flash ARM perform the task programming fails.
    In looking at the output log I see that J-Flash uses 0xAAAA and 0x5554 as the address offsets in the command sequence. According to the Spansion documentation the address offsets should be 0xAAA and 0x554.
    According to the Spansion S29NS128P data sheet Amax – A14 are don’t cares, so the 0xAAAA and 0x5554 offsets would not be the same as 0xAAA and 0x554. Many of the NOR flash parts are Amax – A11 are don’t cares, and for these parts the two address offsets would be equivalent.

    So, is there some way to force J-Flash to only use 12bit addresses for the command sequence? Or, am I possibly missing something?
    I have verified that for example the following sequence will work in the CPU tab if entered manually:

    Source Code

    1. JLINKARM_WriteU16(0x20000000, 0x00F0)
    2. JLINKARM_WriteU16(0x20000AAA, 0x00AA)
    3. JLINKARM_WriteU16(0x20000554, 0x0055)
    4. JLINKARM_WriteU16(0x20000AAA, 0x00A0)
    5. JLINKARM_WriteU16(0x20000000, 0x1234)
    6. JLINKARM_WriteU16(0x20000000, 0x00F0)


    The following does not work:

    Source Code

    1. JLINKARM_WriteU16(0x20000000, 0x00F0)
    2. JLINKARM_WriteU16(0x2000AAAA, 0x00AA)
    3. JLINKARM_WriteU16(0x20005554, 0x0055)
    4. JLINKARM_WriteU16(0x2000AAAA, 0x00A0)
    5. JLINKARM_WriteU16(0x20000000, 0x1234)
    6. JLINKARM_WriteU16(0x20000000, 0x00F0)

    Thanks,
    Ossian
  • Hi Ossian,

    indeed it sounds like a problem on the J-Link / J-Flash side.
    Do you think it is possible to send us your hardware so we
    can reproduce it here and work on a solution (should be no big deal to fix this)?


    Best regards
    Alex
    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.
  • Hi Ossian,

    unfortunately you were not able to send us a hardware in order to reproduce this.
    So we decided to change our algorithm as follows:

    First erasing/programming using 16-bit offsets is tried. If this fails, 12-bit offsets are used.
    This should work in your case (Could not be fully tested, since we do not have a hardware here which shows the described problem).

    For now this adaption will only be implemented for the "RAMCode version" which is used if "Use target RAM (faster)" is selected.

    The adaption will be available in the next beta version of J-Flash, which comes later today (V4.15c)

    Best regards
    Alex
    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.
  • Still can't get J-Flash to program the Spansion S29NS128P

    Hello Alex,

    Thank you for posting the beta update V4.15d of the J-Flash application. Following your instructions I'm still not able to get programing to work. Using the "User target RAM" setting it is difficult to tell from the log out put what is happening. Any suggestions on how to make this more readable?
    With "User target RAM" disabled it is easy to see from the log where things are going wrong, but as you indicated with the fix in V4.15d not using the "target RAM" option will not work.
    Is it possible to get a version that works without enabling the "User target RAM" option?

    I have attached the Spansion S29NS-P data sheet, hopefully this will help provide a better understanding of the issues. Note the notes on pages 79 and 81. Also by default DYB is set (protected) for every sector on startup, so all sectors must have DYB cleared. My plan was to perform this task for every sector through the J-Flash scripting, but it would be nice if this happened automatically.
    The J-Flash application indicates that the Spansion S29WS128P is supported. Although I don't have the S29WS128P, looking through its data sheet it looks like the S29WS128P would have similar addressing issues as the S29NS128. I have tried manually forcing J-Flash to use the S29WS128P option, but this is not working and when I look at the output log it still looks like it is using 16-bit offsets?

    Please let me know if any of the output logs from the J-Flash would be helpful in resolving this issue. Also let me know if you have any other versions of J-Flash that I can try. Is it possible to get a version of J-Flash with 12-bit offsets that does not require "User target RAM"? Obviously once everything is working I will want to switch to using the "User target RAM" option since everything programs much faster under this configuration.

    Thanks for all you help,
    Ossian
  • S29NS-P data sheet too large

    It looks like I can't post the Spansion S29NS-P data sheet because it is too large.
    Let me know if the data sheet would be helpful and how best I can get this to you.

    Thanks,
    Ossian
  • Hi Ossian,

    our AMD algorithm supports 16- and 12-bit offsets since J-Flash V4.15c, so it should work for all AMD-algo flash devices
    (Those which need 12-bit offsets, those which need 16-bit offsets and those which work with both)

    Since you are not able to send us a hardware for investigation,
    unfortunately there is nothing more we can do for you at this point.

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

    Thank you for the response. Are you saying that not using the "Use Target RAM" should still produce the correct programming algorithm?
    Is there any way for me to verify from the log outputs that Segger's AMD programming algorithm is correctly switching to 12-bit offsets?

    Thanks,
    Ossian
  • Hi Ossian,

    maybe I was not clear enough in my last post:
    The 16/12-bit offset switching is performed only, if "Use target RAM" is activated.

    If "Use target RAM" is activated, the programming is done by the RAMCode which is loaded into the targets RAM.
    So no, J-Flash can not log what exactly is performed by the RAMCode.
    But we have verified (in a special provoked scenario) that if programming using 16-bit offsets fails,
    12-bit offsets are used and the RAMCode tries programming again.

    Best regards
    Alex
    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.