My 9s12c32 won't load programs correctly via the BDM.
I do not want to be rude and I am sorry but you request sounds like "My car stops. Why?"
1)What kind of design, board you use. Was it working correctly before. Does the device produce bus clocks in special mode at given pin...(just to check the clock is correct)
2) What report do you receive while you try to program device? ....device secured, wrong address, bdm has no connection,...
3) What is the description of the process you are doing. What IDE, programmer, BDM interface you use.
4) You use stand alone programmer or the problem is to load the code from IDE for debugging.
Could you please refine your question.
You're right, I should've supplied more info. Here it is. The board I'm using is of my own design; it's simply a wall clock. The MC9S12C32 is connected via SPI to a M41T93 RTC, a New Haven LCD and a MAX7221 LED driver. Yes, the circuit was working before for some several months. The environment is Code Warrior and the programmer is a PE Microsystems USB Multilink.
The problem occurred when I was reprogramming the 9SC32; I think I removed the BDM cable too soon. Now there are no error messages of any kind when code is loaded; it appears to load normally. But now, when the new clock code is loaded, rather than the Source window in the Debugger screen going to the first line of code in the main program, like normal, I am in Start12.c code. When I attempt to run the code it doesn't run, but appears to be executing a few lines of assembler code before it stops when you watch the Assembly window. In the Assembly window all you see is BGND in each location. Also in the Command window I see an ILLEGAL_BP message.
One of the troubleshooting tests I did was to load a simple program to just toggle an I/O pin; this worked. The behavior of the IDE was normal. Further, I tested with some simple functions to initialize the LCD and show a cursor; this worked and again, the IDE behavior was normal. However as soon as code that uses a function with a parameter is inserted, like trying to write a string to the LCD with a function that gets passed a pointer, the unusual behavior described above is the result.
The processor always runs as evidenced by the signal on the Eclk pin.
I thought maybe as a result of the BDM cable being removed too soon that the part may have been "secured" even though I don't know how a secured part behaves. So I used a PE Micro tool to unsecure it. But it wasn't secured.
I hope you can help because sure am stuck.
I am sorry for later response because of my absence.
I’d like to provide you following suggestions.
ILLEGAL_BP leads me to a SW issue. The message is usually reported when the debugger get lost – typically unexpected interrupt or reset. So it leads me to direct you to solution described in
for another MCU and also I would like to ask you to check the reset pin whether there is no repeating reset.
Probably it would be also to check pull resistors at XIRQ, IRQ pins, Test pin (GND),…entire MCU environment. https://community.nxp.com/docs/DOC-93775.
You can also check MODA. MODB levels whether pull-down are correct.
You can also check compiler setup. You should have compiler settings – small memory model (-Ms) and parameter -OnB=b (if you use ROM_4000 for code.
Thank you so much for spending time thinking about my problem. The XIRQ input is not pulled high but XIRQ ints are not enabled. Guess maybe that pin should've been pulled high just to be safe. But again, this circuit has been working for months prior to the current problem. The MODA and MODB pins are not bonded out on this part. The IRQ pin is used: a 1 Hz signal from the RTC is fed in to the IRQ. The Test pin is hardwired to GND. The Reset pin is pulled high with a 10k, but I haven't checked for spurious resets; I'll do that.
I looked at the link you provided. An unexpected interrupt is certainly something that I'll check.
Thanks again for the help.
Retrieving data ...