Problem with Flasher 5 reading ST92F120

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

  • Problem with Flasher 5 reading ST92F120

    I'm sure I'm missing something simple here but I am having a problem using Flasher 5 to read ST92F120 MCU's. I can however read a ST92F250 without a problem. I know I have the connections OK and I have scoped the waveforms to make sure nothing is wrong there. No matter what I try I always get 'Ramcode does not work' with the ST92F120's (I have tried with a couple of ST92F120V1Q7's and a ST92F120V9Q7 with the same result). I have also had a logic analyser connected to view the data being transmitted and received:


    After reset (with the flasher holding SOut low), the ST92F120/250 sends 25 on SOut. The flasher responds with 23 on SIn and the ST replies with the ready to receive 21 (as it does from now on after each byte is received). The flasher then sends the 008E (number of bytes to be sent to the ST). The flasher sends the 4 SCI interupt vectors 0008, FFFF, FFFF and FFFF. This is followed by the rest of the 8E bytes:


    FE C7 00 C7 62 F5 FC 00 F5 FD 0A C7 DE F5 F6 01
    BF DE 03 D0 FF FF FF FF FF FF C6 DE F7 F5 F2 09
    C7 62 F5 F6 92 00 F5 F8 02 EF 01 08 F8 F5 F8 04
    EF 01 18 F8 F5 F8 08 EF 01 C8 F8 F5 F8 10 EF 01
    B8 F8 F5 F8 20 EF 01 D8 F8 C7 62 F5 F8 22 EF 01
    D8 F8 C7 56 C9 F0 C7 62 B5 80 97 D1 3F FF 6B 04
    DF D0 8B 14 BF D0 00 00 50 DC C7 56 C9 F0 C7 02
    F5 F9 AA F5 F9 55 C7 62 C7 62 89 F8 EF 01 D8 F8
    8B D6 FF BF 01 FF


    These bytes are the same for both ST92F120 and ST92F250. The final 21 is sent from the ST asking for the end of transmission byte. The flasher replies with 55. Following on from the above (including the 01 and FF from the end of the 8E bytes) the following are the bytes sent and received to read 0x2000 bytes from 0x00:


    From a ST92F250...
    SOut: 21 21 21 02 04 08 10 20 22 01 00 00 5A 01 00 01...
    SIn : 01 FF 55 00 00 00 00 00 55 55 55 55 55 55 55 55...
    where 01 00 00 5A 01 00 01 are the first 6 bytes from the ST @ 0x00


    From a ST92F120...
    SOut: 21 21 21 02
    SIn : 01 FF 55 00
    as you can see the last bytes sent/received are the 02 from the ST and the 00 from the flasher. Thats it, the ST then does not do anything.


    Am I wrong in thinking the ST has accepted the code sent to it and has actually executed a few instructions? Is there anything I am missing? Any ideas greatly appreciated.


    Thanks in advance...

  • OK then. Is it possible to alter the RAMcode sent to the ST9. I would like to try my own custom code.

    Also, I can see in the Flasher 5 firmware there are what looks like 3 (?) different RAMcode implementations for all of the selectable ST92 MCUs under the Options/Device menu. I have monitored all data sent to the MCU for every possible ST92 device selected and every time its exactly the same RAMcode (the RAMcode that works for the ST92F250).

    Should the RAMcode be identical for every ST9 device listed in the Flasher software?

    All the above with Flasher V2.00i and Firmware 5.30 (and same result with Firmware 5.31)

    The post was edited 3 times, last by timstewart ().

  • Hello,
    sorry for the late reply.
    For ST9 access, we use 4 different RAMCODEs.
    One for blank check, one for programming, one for erasure and one for reading the device.
    We use the same RAMCODEs for all devices (120, 124, 150 and 250).
    We never had problems with this.
    I verified the function with two of my application boards today, one equipped with an ST92F120V1Q7,
    one with an 92F250CV2Q3.
    All functions of Flasher worked without any problem on both boards.
    We are not aware that anything may have been changed in the smaller devices, but we will contact ST.
    Did you try different interface speeds?
    Flasher may be set to Fast and Slow in the device properties.
    Your communication dump shows, that the RAMCODE was loaded correctly and started.
    The last byte sent from the device on SOUT (02) is the first byte sent from the running RAMCODE.
    Right now, I don't have an idea why the code dies after sending the byte.
    The RAMCODEs we use are sample codes which came from ST originally.
    The RAMCODEs are part of the firmware and can not be replaced by own RAMCODEs.
    Would it be possible to get one of your devices or an application board to analyze the problem here?
    What is the operating frequency of your target application?
    What watchdog options did you implement?
    Regards,
    Armin