MC68HC908GP32 + CW v6.3 +MON08

[krzysztofkt]

Hello, community.

I request for a HELP!.

Have chip MC68HC908GP32 brand new from ebay market. Have donwloaded and installed CodeWarrior special edidtion 6.3 that handle this family of MCU. I connect via hardware serial port nad self made MON08 interface.

I can not pass security code. Cennection status summary: 6xY and the last one "N". When choose IGNORE security bytes, MCU entered the monitor mode, and CW ask for erase flash.. but after attempt of mass erase everything looks like ok, but security byte acces is still denied and ERROR 48 occur.

When i IGNORE the security bytes and dont try erase chip, i can read RAM memory, flash memory range is all &AD.

The &040 RAM memory adress is 7F, so the 6'th bit is "1" that indicate that security code is correct (datasheet) but it's not.

In Mon08Interface/View Register Files.. i found Flash Block Protect Register

I can change bits 00, 01, 02 and 03 to "0" or "1" but i can not save any change. The Value of this register is &AD looks like other &AD in secured location of memory.

Interesting thing is that on the window i can see that Flash block protect register is in &FF80 adress, and in datasheet i can read that FLBPR byte should be at  &FF7E adress... This is correct ???

Also i found flash control register window. There i can set or reset PGM erase mass or HVEN bit. And it works i can save change to register. So i decided to try try mass erase by-hand. With Datasheet i do step by step manually.

I set Erase and MASS bit, Read flash block protection register and try to change some bits and try to save it. then I set the HVEN bit. After that i try to reset "0" bit Erase and MAss but when I enter the flash protection block register, there is MASS bit allready "0".. Looks like it is automatically clear when i set HVEN. Becouse like on the NOTE on image the MASS erase is disabled whenever any block is protected FLBPR does not equal &FF. Andf its true becouse on FLBPR register i can read &AD..

Can some one tell me what im doing wrong, or where looking for solve this problem ??

Regards

Chriss

[krzysztofkt]

Some one ??? Any help ?? ANY suggestions ?? Factory suport ??

[mfugere]

I am not sure if I can be of much help.  I have encountered a similar problem as this when using the PEMicro's HC08PROG flash programming utility with their Multilink MON08 pod.   It was resolved with update to the drivers I was using from PE Micro, and making sure that I left the "unsecure flash" setting off as well as the "ignore security " setting checked/on.   Are you using an interface like the megasquirt to connect to the chip?     Unfortunately I no longer have the MON08 pod with me as we have migrated our product to MC9S08AC60, because the MC908GP32 is going up in price and becoming harder to get.  Before much longer it may be made obsolete, or at least much more expensive - it is already more than 2X the price of the AC60 which has much more capability.   If you are using GP32 for learning/home experiments that is fine, but I think I would look at some of the 9S08 family of chips if you are working on a product to sell.

Sorry I am not of much help,

M

[krzysztofkt]

Hello, thank you for your reply..

Yes i use programator like megasquirt programmer, it's easy to build and free for schematics.

I not sure what is that "unsecure flash" ?? where i can find this option ? I know only about "ignose security bytes".

Thats true thisd mc68hc908Gp32 is old..

About MC9S08AC32 in datasheet i can see that FLASH memory is start from &8000 adress same like in HC908GP32. IS this pssible to load program form GP32 in to MC9S08AC32 with any changes ??

[scottm]

If you use the ignore/force option, you're supposed to have the ability to mass erase the device, which also removes the security. I've used several P&E devices over the years and in my experience, if it successfully connects with the 'ignore' option but keeps saying it's secure after an erase, there's something else wrong.  That could be as simple as a fried MCU.  If you have another to test with, I'd start there.

Also, having the wrong programming algorithm might give you that kind of problem.  I've had so many versions of the software installed over the years that I've often had several versions to choose from and some will work but not others.  Probably depends on the software version and the programmer firmware version.

Scott

[mfugere]

I think that I am remembering a setting from PROGHC08 utility from PEMicro - the "Erase Module" function has an option to"Unsecure Flash" so that it clears all flash protect bits after erasing the chip's flash memory.   I haven't tried that within CW yet, and am now working with 9S08 chips.

The 9S08AC32 architecture is somewhat different from MC908GP32 -

Some of the Port IO pins are not the same, and are attached to different pins

Various peripherals registers are at  different addresses within the chip

Some  peripherals, such as ICG clock module, and Timer module (TPM3 instead of TIM) have different registers and settings.  I also found (Sadly) that some things with ICG Clock module will not allow me to achieve same busclock/peripheral clock rate as with GP32, which forced me to adjust and recalcualte formulas for control and Time Domain Reflectometry functions.

So, you cannot use same compiled program file for 9S08AC32 as 908GP32, but it is possible to port over.  Depending upon what functions, pins, and peripherals you are using, it might not be too bad to do, in some cases, it is a fair amount of effort!   One advantage (or disadvantage) of 9S08AC32 is that the CPU runs at 2X the BusClk rate (CPU  runs at BusClk rate on GP32) so you have much faster CPU instruction execution.... though this change to timing also impacts your application code considerably if you have any software delay loops.