MCU dead due to bad code?

Hi everybody!
I have some trouble with the OKI 675001: I'm using this part now for
about 3 month, debugging and programming an extern Flash (AM29LV320)
via JTAG. Never had any problems. Now after changing the code and
burning it as usual into the FlashROM the MCU is no longer responding
to JTAG. Furthermore no activity on the MCU bus. OK, i thought that
some ESD distroyed the MPU and took a new part. But the same happend
again :(.
Here the proceeding in detail:
- via JTAG initialization- and flash program loaded into internal RAM
- initialization of SDRAM with that code -> breakpoint
- via JTAG flash data loaded into SDRAM
- flash program started -> breakpoint
- everything still works
- hardware reset -> MCU dead
(I'm using the Amontec Chameleon with the "Raven 8MHz witout Reset"
configuration.)

How can code destroy/disable the MCU? Can i somehow resurrect it?
Any help appreciated, Tom

<th@tixi.com> wrote in message 
news:1148372917.387054.244090@g10g2000cwb.googlegroups.com...
> Hi everybody!
> I have some trouble with the OKI 675001: I'm using this part now for
> about 3 month, debugging and programming an extern Flash (AM29LV320)
> via JTAG. Never had any problems. Now after changing the code and
> burning it as usual into the FlashROM the MCU is no longer responding
> to JTAG. Furthermore no activity on the MCU bus. OK, i thought that
> some ESD distroyed the MPU and took a new part. But the same happend
> again :(.
> Here the proceeding in detail:
> - via JTAG initialization- and flash program loaded into internal RAM
> - initialization of SDRAM with that code -> breakpoint
> - via JTAG flash data loaded into SDRAM
> - flash program started -> breakpoint
> - everything still works
> - hardware reset -> MCU dead
> (I'm using the Amontec Chameleon with the "Raven 8MHz witout Reset"
> configuration.)
>
> How can code destroy/disable the MCU? Can i somehow resurrect it?
> Any help appreciated, Tom

Could it be that bad code in the flash is crashing and locking up the MCU 
which also hangs the JTAG? Try forcing the chip select on the flash on power 
up so that the code in the flash doesn't get accessed. Or try to get the 
JTAG to connect as soon as you release the reset - you might get lucky. 

Actually i didn't find anything about this MCU that could cause such a
behaviour.
The fast reset and jtag approach didn't work  But now i'll disconnect
the Flash and pray.

Even without the flash the MCU doesn't respond to JTAG. I'm affraid the
chips are toasted, but how. It's very strange :((.

th@tixi.com wrote:
> Hi everybody!
> I have some trouble with the OKI 675001: I'm using this part now for
> about 3 month, debugging and programming an extern Flash (AM29LV320)
> via JTAG. Never had any problems. Now after changing the code and
> burning it as usual into the FlashROM the MCU is no longer responding
> to JTAG. Furthermore no activity on the MCU bus. OK, i thought that
> some ESD distroyed the MPU and took a new part. But the same happend
> again :(.
> Here the proceeding in detail:
> - via JTAG initialization- and flash program loaded into internal RAM
> - initialization of SDRAM with that code -> breakpoint
> - via JTAG flash data loaded into SDRAM
> - flash program started -> breakpoint
> - everything still works
> - hardware reset -> MCU dead
> (I'm using the Amontec Chameleon with the "Raven 8MHz witout Reset"
> configuration.)
> 
> How can code destroy/disable the MCU? Can i somehow resurrect it?
> Any help appreciated, Tom
> 

I am not familiar with the OKI processors, but is it possible that there 
is a clock configuration register in flash that is being mis-configured? 
I have seen clock and bus configuration registers on other processors 
that would cause this kind of problem. Another thought would be some 
kind of security bit.


Good Luck,
Bob

th@tixi.com wrote:

> Hi everybody!
> I have some trouble with the OKI 675001: I'm using this part now for
> about 3 month, debugging and programming an extern Flash (AM29LV320)
> via JTAG. Never had any problems. Now after changing the code and
> burning it as usual into the FlashROM the MCU is no longer responding
> to JTAG. Furthermore no activity on the MCU bus. OK, i thought that
> some ESD distroyed the MPU and took a new part. But the same happend
> again :(.
> Here the proceeding in detail:
> - via JTAG initialization- and flash program loaded into internal RAM
> - initialization of SDRAM with that code -> breakpoint
> - via JTAG flash data loaded into SDRAM
> - flash program started -> breakpoint
> - everything still works
> - hardware reset -> MCU dead
> (I'm using the Amontec Chameleon with the "Raven 8MHz witout Reset"
> configuration.)
> 
> How can code destroy/disable the MCU? Can i somehow resurrect it?
> Any help appreciated, Tom

  You don't say if you tried going back to code that you know worked,
or if you tried a power-cycle-wait-hard-reset ?
  It is believable that a CPU would have a JTAG disable that does not
recover on RESET ( surprising how many chips have reset pins that are
better called reset request ... )

Otherwise you may have stumbled onto a undocumented HCF opcode ?

-jg

<th@tixi.com> wrote in message 
news:1148394777.134474.298730@j55g2000cwa.googlegroups.com...
> Even without the flash the MCU doesn't respond to JTAG. I'm affraid the
> chips are toasted, but how. It's very strange :((.
>

It seems unlikely but it is possible. I had a touchscreen that turned its 
toes up at the same time as I made a tweak to it's driver software, purely 
by coincidence. Cue many hours of debugging a working driver. 

I tried a power-cycle-wait-hard-reset. The wait part was several hours.

According to the documentation there is no possibility to disable JTAG
(only by toasting the chip , as i did *grin). Of course there could be
something with the ROM timig, but JTAG should always work, it even
works without any extern ROM/RAM etc.
Some processors have JTAG disabling flags, but this type don't.
Even if i connect BSEL1 to GND (enabling the internal BootROM) i can't
connect with JTAG. In that case the external ROM shouldn't cause any
problem.

On one of the project that we were on, we had similar programming
problems. We finally track it down JTAG programmer was being driven on.
 If it was one of the parallel port driven ones, you may to reduce the
JTAG clock right down.

flaretom wrote:
> I tried a power-cycle-wait-hard-reset. The wait part was several hours.
>
> According to the documentation there is no possibility to disable JTAG
> (only by toasting the chip , as i did *grin). Of course there could be
> something with the ROM timig, but JTAG should always work, it even
> works without any extern ROM/RAM etc.
> Some processors have JTAG disabling flags, but this type don't.
> Even if i connect BSEL1 to GND (enabling the internal BootROM) i can't
> connect with JTAG. In that case the external ROM shouldn't cause any
> problem.

Hi!

The problem is solved!
In my code the RMPCON register is set to 9 switching the DRAM bank to
zero address. But at this point the SDRAM controller isn't initialized
yet. This seams to disturb the MCU and even the JTAG interface gets
locked.
By activating the internal BootROM (BSEL1=0) the malicious code is
disabled and it's possible to connect via JTAG.
I tried that approach before, but somewho it didnt't worked. I can only
guess that the connection of BSEL1 to GND was not right.
OKI Germany was very helpfully and actually they found the solution.
After checking the BSEL1 setting i was able to reactivate all my
"toasted" boards :)).

Thanks to all who tried to help!