9s12xDT512 will not program; P&E mulitlink USB V2.0

[blewis]

We are using version V5.7 of CW which is supposted to support the 9s12x parts. We have a board that uses the 9s12DG128B with a Pierce oscillator which works perfectly.

We mounted a 9s12xDT512 on the board and it talks to the BDM but will not program the 9s12xDT512 part. Support suggested the part was bad so we changed it but the new part behaves exactly the same. We can write memory using NoICE, but CW will not write the memory. CW thinks the part is secured, but running the UnSecure program from P&E indicates the part is not secured.

I am beginning to think that this may be a P&E mulilink pod problem. I noted that some one else thought the pod might be a problem. NoICE does not support the programing algorithms yet for the 9s12x part but will in the future so we can't even check if the problem is CW. We only have the P&E prob.

Has anyone experience this sort of problem, and are there any work arounds?

Thanks in advance.

Bob Lewis

[mke_et]

I fail to see how it could be the pod, but I susspose anything is possible. 

I'd look to make sure you have the processor type set up right first.  When I did my first project, I did all the developement with the 9S12DP256B with a 9S12Badge attached to a wirewrap board.  Then chose that part for my project, even though it was overkill.

My second 9S12 project I used the the 9S12DG128 in an 80-pin package.  This project was a 'redesign' of an existing project that had a 68HC11 part on it with a WaferScale expansion part.  To develope the project, I pulled the CPU and WaferScale parts off an existing and known working board and mounted a 9S12Badge board right next to it, then 'wirewrapped' the two together.  However, when my new design board samples came in, I tried to program the DG part and ran into a similar situation to what you described.  Eventually I figured out I had to change my CPU type in the ICD-12 'Set Derivative' option and things started falling together.

[rhinoceroshead]

What crystal frequency are you using?  Is it possible that the timing is not correct for the Flash module?  My home-made DP512 board uses a 4 MHz crystal and I've never had problems writing to the Flash.  I chose that crystal because the DEMO DT512 board used it.  I know when you write the Flash run-time in your program you have to ensure the FCLK is within a certain range of frequencies.  The programming software may be assuming you are using one crystal and you may be using something different.  Just a thought.

[blewis]

Thanks for the reply; we are using a 16Mhz crystal. We use CW project expert to build the system, and in there we have specified the freq to be 16Mhz. I think that CW adjusts the programing clocks based on those numbers. I know what you are referring to however, the eeprom has to be also adjusted correctly or it will not program. We used to have that problem with another tool set.

[rhinoceroshead]

Well, I agree with mke - it can't be the POD, otherwise you wouldn't be able to write to RAM either.  And with two devices showing the same issue, it's not very likely that both of the chips have bad Flash.  Also - a secure chip should not be the problem either - because the BDM can erase a secure chip.  Since only the Flash module itself appears to be having problems, that is why I suspected the timing.

I thought the processor expert only wanted to know the crystal frequency so that it could write the proper dividers in software for PLL, ADC, SCI, FLASH, etc.  I'm not so sure that it has any relation to timing for the BDM and programming the Flash during development - but I could easily be wrong here.  What happens if you open the Hiwave debugger and go to the ICD-12 drop down and select 'Set Communication Speed'.  I doubt this will help because it is clearly already communicating.  Perhaps someone else on this forum can confirm that it works with a non-4MHz crystal without changing any settings...

You are certain that all of the power pin traces on the board are correct, yes?  And also the reset pin is connected to the BDM port?  When I built mine, it just worked immediately with no fuss, and still works almost a year later.  I've reprogrammed it hundreds of times without the slightest hint of a problem.