Cart New Account Login

HomeAbout usProductsSupportForumsBlogCustomer Service

search inside this forum
search inside all forums
Cannot erase modules with Prog08sz
Marshall S. migrated on Dec 31, 2013 at 11:00 AM
No staff assigned yet

  • Hey all, this will likely be long as I want to be as descriptive as possible in my process as to find an error.

    I am using Prog08sz for HC08 Microcontrollers (MCU) v2.32 fresh downloaded yesterday with the new algorithms.

    I am using 4 types of MCUs atm:
    MC908AS60ACFU (referenced from now on: AS60)
    MC908AZ60ACFUE (AZ60)
    MC9S08QE128-LQFP80 (QE128)
    MC9S08GT60CFD (GT60)


    I believe the QE128/GT60 are HCS08 MCUs, and therefore, requires CPROG08SZ? My attempts at programming these with prog08sz is close to none, but I've been told it has been done before.

    Short story is I am capable of programming the AS60, but NOT capable of programming the AZ60 - here's my approach:
    Open Prog08SZ and initial setup is Class 1, baud 8661, ignore security failure is ticked, and show dialog box also ticked - this is the only setup that can actually connect to the device. I don't fully understand the security bytes, but I have yet to succeed checking any radio button other than ignore unless I have gotten a full erase, checked memory to see if it is 0x00's or 0xff's and using that for security.

    1) Contact Target
    2) Select Algorithm:
    keep in mind the AS60 is connected - Naturally I select the AS60 alg (same result with AS60 highspeed) - it loads. I try to erase module and I get "Erasure of secure device done. Forcing power down to bypass security" and get returned back to the initial setup GUI. I hit recontact and it reloads previously selected alg (sometimes I have to recycle power to MCU) and then I blank check and find that the device was never actually erased. Programming yields "Error in programming module". Checking memory yields a majority of memory is 0xAD with some sections at 0xFF and some at 0xUU... no beans.

    So I try AS60A and highspeed algorithms thinking this might be the cause - once I try to load the algorithm prog08sz crashes every time.

    Out of curiosity I try AZ60 and highspeed. The algorithms curiously load. Erasing the device (if this is a fresh run of prog08 - if not I get same error as AS60) shows a different result. I get a little bar that rotates for a couple seconds and then a message "Module has been erased". I blank check and it is confirmed. I can then select my .s19 object file and program flawlessly.

    So the AS60 MCU programs under the AZ60 alg is moral of that story.

    So now I move on to the AZ60 MCU. I have tried every algorithm (AS60, AS60A, AZ60, AZ60A) I would find reasonably acceptable to no avail getting the same [failure] erased message above.
    /* Edited 2/3/2010 for more information */
    I try to erase module and I get "Erasure of secure device done. Forcing power down to bypass security" and get returned back to the initial setup GUI. I ignore security bytes again and reconnect, but keep returning to this GUI unless I cycle power on the MCU. After cycling power on the MCU and I connect - prog08sz tries to automatically reload the AZ60A algorithm and it always fails. Looks like this:
    "Loading programming algorithm...Error writing data to part...continuing....error writing data to part...continuing...error writing data block to part. disabling block write. try again. error enabling module just selected."

    After the erasing doesn't it try to perform a power-on reset? So me manually cycling power on the device should perform this, correct?

    I am thinking the problem is this, since I do not know the security bytes it won't allow me to erase so I have to perform a mass erase or bulk erase and I am not sure on how to do this. Every manual I find tells me to do what I've been doing - ignore security and hit erase module... and since this hasn't been working I am beginning to wonder where during the erase it fails and if I should be losing connection to my target to go back to the initial setup screen?
    /* End edit */

    These are all MCU's with previously loaded code on them. This previously loaded code I have probably broken as the MCU no longer functions how it used to - and loading the .s19 files from the previous SW version does not pass the security bytes properly.

    Any help you can offer is appreciated, please ask questions if you need/want more information.


    //edit
    Guess I should comment on my physical setup. I have a M68HC08 Serial Programmer. Host serially connected to PC, powered by external power supply (5V). There are 2 slots of 10 pins - I have tried both and both seem to work on the AS60. Pin 1 is connected to GND and pin 8 (programming line) is PTA0 I believe on MCU - only 2 pins used for all setups.

    //edit2
    Added GT60




    Comments

  • I am 90% sure the only difference between the working MCU and the non-working MCU is the fact that after I try re-contacting the device when it works I am able to reload the algorithm, when it doesn't work when I try reloading the algorithm I get the failed message described above. This inclines me to think that I am not choosing the algorithm correctly or there is an error on the algorithm. (Chose the AZ60 algorithm for the AS60 MCU, choosing the AZ60A algorithm for the AZ60(A) MCU above).

    //edit
    Really haven't changed much, but was able to reload the algorithm the 2nd time ONLY AFTER "Disabling block write. Try Again.". After those messages it has a CHANCE to say "Done." In which a blank check fails - however - attempt to program will go ?a block? from 0x8000 to 0x8080 before failing (as opposed to earlier just failing the second it starts at 0x8000).

    This leads me to conclude something is wrong with writing blocks (as it failed writing the algorithm AND program) - not sure if it's still related to the AZ60A algorithm though...could be?

  • QUOTE (MSchiring @ Feb 4 2010, 03:37 AM) [legacy comment]
    I am 90% sure the only difference between the working MCU and the non-working MCU is the fact that after I try re-contacting the device when it works I am able to reload the algorithm, when it doesn't work when I try reloading the algorithm I get the failed message described above. This inclines me to think that I am not choosing the algorithm correctly or there is an error on the algorithm. (Chose the AZ60 algorithm for the AS60 MCU, choosing the AZ60A algorithm for the AZ60(A) MCU above).

    //edit
    Really haven't changed much, but was able to reload the algorithm the 2nd time ONLY AFTER "Disabling block write. Try Again.". After those messages it has a CHANCE to say "Done." In which a blank check fails - however - attempt to program will go ?a block? from 0x8000 to 0x8080 before failing (as opposed to earlier just failing the second it starts at 0x8000).

    This leads me to conclude something is wrong with writing blocks (as it failed writing the algorithm AND program) - not sure if it's still related to the AZ60A algorithm though...could be?


    Hello,

    HC08 devices use a different hardware interface than S08 ones. MON08 compared to BDM
    What adapter are you using between the computer and the MCU and how are you connecting it?

    regards
    Peg

  • QUOTE (Peg @ Feb 4 2010, 09:20 PM) [legacy comment]
    Hello,

    HC08 devices use a different hardware interface than S08 ones. MON08 compared to BDM
    What adapter are you using between the computer and the MCU and how are you connecting it?

    regards
    Peg


    Hello Peg,

    I am using the PC serially connected to (not USB) to a port labeled "Host" on the M68HC08 Serial Programmer - I am not so concerned with the S08 devices at this time. This serial programmer then has two 10 pin connectors (looks like it can support programming 2 devices at once) and requires an external 5V power supply. In documentation it would seem only 2 of these 10 pins are needed to be attached to the MCU. Pin 1 looks like GND and Pin 8 looks like data line (PTA0?).

    Thanks,
    Marshall

  • Steps to most recent "breakthrough"

    1) connect to device ignoring security bytes
    2) select AZ60A algorithm
    3) Erase Module - says Erasure of secure device down... which then tries to POR and goes back to initial connect window
    4) Power down MCU, disconnect programming cable and reinsert/power on then Reconnect ignoring security bytes
    5) Algorithm will fail at least 2 times (prog08sz automatically will try 3 times). The 3rd time MAY "appear" succeeded by saying "Done." The console may also display something about disabling page erasing and succeed.
    6) Blank check module - 100% will hang prog08sz's connection. The box asking to ping/reset/halt will come up. I sometimes ping a few times for fun with no visual response then I hit reset.
    7) Back to initial connection gui. power down and disconnect programming cable, reinsert/power on and reconnect ignoring security bytes
    8) After making a connection and before reloading algorithm - status window will display a single line reading "Erased" as if the blank module command has finally come through reporting the target is erased.

    Now I can try programming and it starts at 0x8000 and fails at 0x8080. I tried "program range" from 0x8000 to 0x807f and succeeded with "Programmed." message for first time! A verify range on the same range fails, because of security bytes returning 0xAD's.

    So it looks like the target IS getting erased (good, because the MCU no longer functions like I would expect if it still had the old code on it), however, I am not able to program it or read due to security bytes ?NOT? being erased.

    Ideas?

  • QUOTE (MSchiring @ Feb 6 2010, 08:40 AM) [legacy comment]
    Steps to most recent "breakthrough"

    1) connect to device ignoring security bytes
    2) select AZ60A algorithm
    3) Erase Module - says Erasure of secure device down... which then tries to POR and goes back to initial connect window
    4) Power down MCU, disconnect programming cable and reinsert/power on then Reconnect ignoring security bytes
    5) Algorithm will fail at least 2 times (prog08sz automatically will try 3 times). The 3rd time MAY "appear" succeeded by saying "Done." The console may also display something about disabling page erasing and succeed.
    6) Blank check module - 100% will hang prog08sz's connection. The box asking to ping/reset/halt will come up. I sometimes ping a few times for fun with no visual response then I hit reset.
    7) Back to initial connection gui. power down and disconnect programming cable, reinsert/power on and reconnect ignoring security bytes
    8) After making a connection and before reloading algorithm - status window will display a single line reading "Erased" as if the blank module command has finally come through reporting the target is erased.

    Now I can try programming and it starts at 0x8000 and fails at 0x8080. I tried "program range" from 0x8000 to 0x807f and succeeded with "Programmed." message for first time! A verify range on the same range fails, because of security bytes returning 0xAD's.

    So it looks like the target IS getting erased (good, because the MCU no longer functions like I would expect if it still had the old code on it), however, I am not able to program it or read due to security bytes ?NOT? being erased.

    Ideas?

    Hello,

    I would suggest you have a look at the Monitor section of the datasheet for the device you are using. Depending on whether the device is programmed or not you need to hold different pins at different levels in order to properly gain access to the device in monitor mode in order to erase/ programme / debug etc. The prog09sz software and your programming adapter should take care of all the details for you but you will need to have all of the applicable signals connected and able to assume the levels required. Good Luck!


  • QUOTE (Peg @ Feb 6 2010, 01:52 AM) [legacy comment]
    Hello,

    I would suggest you have a look at the Monitor section of the datasheet for the device you are using. Depending on whether the device is programmed or not you need to hold different pins at different levels in order to properly gain access to the device in monitor mode in order to erase/ programme / debug etc. The prog09sz software and your programming adapter should take care of all the details for you but you will need to have all of the applicable signals connected and able to assume the levels required. Good Luck!


    Good idea, I'll check the voltage levels of those pins. I guess I was under the assumption these pins needed to be set appropriately just to enter monitor mode, however, the error might be when the software is attempting to make a POR and these pins are no longer in that state.

    //edit
    The pins are in the state I need them in (below).

    IRQ is only at 8V (should be 7-9V)
    PTC0 is at 5V (expected)
    PTC1 is at 0V (expected)
    PTC3 is at 0V (option)
    PTA0 is at 5V (expected)

  • QUOTE (MSchiring @ Feb 8 2010, 08:39 AM) [legacy comment]
    Good idea, I'll check the voltage levels of those pins. I guess I was under the assumption these pins needed to be set appropriately just to enter monitor mode, however, the error might be when the software is attempting to make a POR and these pins are no longer in that state.

    //edit
    The pins are in the state I need them in (below).

    IRQ is only at 8V (should be 7-9V)
    PTC0 is at 5V (expected)
    PTC1 is at 0V (expected)
    PTC3 is at 0V (option)
    PTA0 is at 5V (expected)



    When attempting to connect to the device with prog08sz the following is sent from PC:
    FF 4A 4A 4A 4A 4A 4A FF 4A 4A

    and the following is read on PC:
    FF 4A 00 4A 4A 00 4A 4A 00 4A FF 4A 00 4A

    Where can I get a manual on the protocol used here to decipher these messages?
    Hardware loop detected: Y
    all others: N


    I have about half a dozen problems across AZ60, AZ60A and AS60 MCU's with this software and none of them are getting resolved and only new ones arise...

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