Cart New Account Login

HomeAbout usProductsSupportForumsBlogCustomer Service

search inside this forum
Starting to doubt that Flash is getting fully erased with Cyclone Pro
Chris T. Dec 19, 2014 at 02:54 PM (14:54 hours)
Staff: Takao Y.

  • I've been seeing some funny results in programming devices with the Cyclone pro that don't show up during debugging.  I can 'fix' the problem by cycling power to my device after I program it, but can't depend on everyone in my company to do that.  So I was hoping that someone would be able to tell me if anything looks weird in my Image creation task list.

    I am using a Freescale 9S12XET256 processor. The flash partitioning was always a little tricky for me - I would learn what I needed to do and then forget about it, so I'm not really confident about how I am doing things.

    Here is what I am entering into the Image Creation Utility:

    CM C:\pemicro\cyclone_pro\Algorithms\9S12XET256\9S12XET256_1x16max16k_max32k_Linear_user_Dflash.12P
    FP 2000
    CM C:\pemicro\cyclone_pro\Algorithms\9S12XET256\9S12XET256_1x16x128k_256k_Linear_Pflash.12P
    SS N:\Chris\Control Code\01 XET256 Code\00 ACE\bin\Project.abs.phy
    EM ;Erase Module
    BM ;Blank Check Module
    PM ;Program Module
    VM ;Verify Module
    RE ;Reset
    GO ;Run




    Comments

  • Greetings,

    Many chips, including yours, must power-cycle to be able to run the code. Just a RESET and GO will not actually do a power-cycle for you. This is why you are seeing odd behavior. Unfortunately, power-cycle to start your code is a feature of the chip, not a bug in the P&E hardware or software.

    My advise to you is to not use RESET and GO, and if you are providing power via the cyclone power relays then you should try powering off your target after programming. This forces the user to power the target back which completes the power cycle. You can set the cyclone's AUX button to provide power to your target by going through the Cyclone MENU options (using the buttons) -> Configure Cyclone -> Set AUX button func -> Toggle Power.

    Hope that gets past the power-cycle "feature" of the HCS12X chip.


    Takao Yamada

  • Thanks for your reply.  This is enlightening - I never thought that would be a problem.

    I actually found what the problem was in the code side of things, which is finished off by this power cycle problem that you mentioned. When the code restarts, it has leftover memory in RAM, and in my code I have specified not to erase the RAM unless power is cycled to the device. I always figured that reprogramming would simulate cycling power to the device, but apparently not.

    Our target board is usually plugged in and powered up before we program it. If I were to use the Toggle Power feature, this would have to be done on a board that didn't have power on it, correct?

  • Greetings,

    If you have external power, then the cyclone does not have control over power so it will not be able to power cycle the target. This feature is only when you allow the cyclone to control power. So in your case, you will need to tell your coworkers to power cycle manually.


    Takao Yamada

  • My understanding is that when I am programming the processor and restarting the program with the Cyclone Pro, my RAM is not being erased.  At least it seems that could be the case.  Is there an option to erase RAM with the Cyclone Pro?  Also, from the program in my above post, how much of the processor is being erased?  I guess I understood the erase command to be erasing everything, especially the EEE memory.

  • Greetings,

    The erase command will only erase whatever the algorithm specifies. So if the algorithm is for flash, then it will only erase and program flash. If the algorithm is for EEPROM, then it will only erase and program EEPROM. Sometimes we have algorithms that combine both. In this case, it will erase and program both sectors.

    RAM is normally not erased because that is where the algorithm resides. When flash programming, the algorithm and portions of your S19 records are dumped into RAM and executing the algorithm commands within RAM. RAM is obviously erased when the power is removed from the chip.


    Takao Yamada

  • So is it true that in my programming sequence above, I am not erasing the EEE memory?  I can't remember what the FP2000 means exactly - I added that a few years ago and now I'm not sure what documentation I was using, if any.  I guess I thought that was erasing the memory.  But are you saying that I would need to add another ERASE command after that algorithm and before the next?

  • Greetings,

    FP stands for flash partition. This sets up your EEE memory and DFlash. After a FP command, you must use the erase command right afterwards to actually execute the partition. Give that a try and see if that gives better results.


    Takao Yamada

  • First of all, Takao Yamada, thank you for your help.  You are bringing clarity to some long standing mysteries.

    Ok, this could explain a lot. I have been programming these boards with this programming sequence for years. And in the past two years there have been a lot of unexplained problems.

    My code looks for bytes in the EEE memory as well as in the RAM to decide whether to initialize EEE (this should only happen once ideally) or to erase the RAM (this should only happen in certain kinds of firmware-initiated resets). If it is true that the EEE memory was not being erased when programmed, then it is possible that the board was getting reprogrammed and retaining the same EEE from the previous program, which could lead to unpredictable results.

    I added this ERASE command after the FP2000 and the board started behaving again. I restored the RESET and the GO commands, and it programmed and ran as it should.

    So this leaves the question: what is the harm in using the RESET and GO commands if the EEE is erased and initialized and the RAM will be erased and initialized by the code?

  • Greetings,

    I am very glad my help is getting you forward progress!

    There are chips that absolutely need a power-on-reset to secure the chip and run the program. Remember that this RESET and GO command is within debug mode. Not in run mode that is ran when no P&E hardware is connected.

    If you plan on securing your chip, RESET and GO can cause big problems. If you use the SD command to secure your chip and then you did a RESET, the chip will attempt to secure the chip but re-enter debug mode again. Entering debug mode when the chip is secured will erase the flash.


    Takao Yamada

  • I have never used the SD command, and never fully understood what it meant to "secure the device."  

    If I do not use the SD command, is it ok to use the RESET and GO commands then?

    Chris

  • Greetings,

    I shall explain to you about security. Without securing the chip, currently anyone could buy a P&E multilink and read the flash and EEE contents of your chip with no resistance. This can be bad if you do not plan on sharing your intellectual property to clients, users, or for misuse.

    By securing the chip no one, including yourself, will not be able to read the flash contents. P&E software and hardware will not be able to enter debug mode. This protects your code and prevents others from changing it.

    There is a way to unsecure the chip. For HCS12X chips like the one you are using, we have a unsecure12 utility you can get in our downloads page. This unsecures the chip which involve erasing all contents of the flash and EEE memory before it can be used again. This again prevents users from reading your code.

    The RESET and GO is fine while you still debug your code. However when you are ready for production, my suggestion is that you do secure the chip at the end and remove RESET and GO commands. More details about security can be found within your chip's reference manual.


    Takao Yamada

  • This brings up another point which has long eluded me.  

    I have never been able to figure out how to examine the flash memory using the MultiLink. Do you know of a document that describes how to do that?

    Chris

  • Greetings,

    You can use either the multilink or your Cyclone pro.

    If you are using P&E PROG software, then you can use the "show module" command after loading the correct algorithm. You can also upload the contents of flash by using the "upload module" command to save the code into an S19 file. Again, this is a reason why securing the chip is important to prevent people from uploading your code. Note, PROG can only read the flash contents and not RAM or registers.

    If you are using P&E's ICD software, then you have the ability to read RAM, FLASH, and registers using the memory windows as long as the chip is not secured.

    Any 3rd party software you will have to read their user guide to find out how to read the memory.


    Takao Yamada

Add comment


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







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