M16C: Binary data download stopps at 90% using KD30 debugger

Hello group, we are using the M16C/62P CPU with a 12MHz external crystal which is then internally increased to 24 MHz (PLL). To prevent dealing with new environmental settings while debugging, we use a monitor program that inreases the clock speed by PLL as well. At the moment we are working with Version

2.02.02 of the monitor.

When loading a binary file into the controller KD30 stopps the download at 90% then dies and never returns. This happens using a monitor where the internal PLL is set to 2. When not using the PLL at all the binary downloads fine.

In an earlier design we used a 6MHz crystal instead of the 12MHz one. There we were forced to use a PLL of 4 to obtain the necessary 24 MHz internal speed. Threre I was only able to upload a binary when using a monitor with a PLL factor of 2. When the PLL was set to 4 KD30 died on me at 90% as well.

Is there some magical speed threshold with KD30 that may not be crossed? When using the binary files and PLL at the necessary speeds without the monitor everything works fine.

Has anybody experienced the same problems And maybe come up with a solution? Or am I just not sticking to the KD30 specification?

Thanks in advance for any kind of answer, Phili

Reply to
Philipp Drewes
Loading thread data ...
[snip]

I experineced the very same thing here too. IMHO it's the monitor program that is faulty. I recommend checking with your supplier.

My workaround to test 24Mhz operation was to simply use a 24Mhz crystal and no PLL. That's of course out of spec but it worked - and most notably it worked with KD30. I then had to lower the speed & use another monitor due to other requirements and hence did not tracked this down completely.

Markus

Reply to
Markus Zingg

Well, then it is at least not just me dealing with the problem. It's a little strange though as I already took a look at the monitor sources. The only difference when it comes to using PLL is that the necessary bits for the clock are set in the PLL registers. Finally the clock source is switched over.

This is pretty much what I do using PLL with my final binary.

It is even more amazing, that the system runs fine as long as the PLL clock does not exceed my 12 MHz threshold

I might try that or I just accept that my timers are a little off then. Most annoying is that the UART communication is totally faulty, too.

What monitor are you working with right now?

Phili

Reply to
Philipp Drewes

I downloaded them from the page of a german supplyer (glyn.de) and they have a script that generates monitors for the whole M16C familly. The monitor is dated Version 2.02.02. I don't know if there are newer ones around. Currently things work nicely for me with the setup I have and since I'm on a tight schedule I don't have the time to try things out.

I think though that for bigger projects it might be well worth it to get the ICE for this thing.

Markus

Reply to
Markus Zingg

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.