Hi guys,
A few questions rolled into one post here, hopefully you can help us before the boss throws the board out of the window. Unfortunately my seat is in front of the window.
Anyway, we have a prototype board which uses the MCF52259 (CAG80*144LQFP). Most of the basics are the same as the M52259EVB eval board, but we've had terrible problems trying to bring the thing to life. We're using CodeWarrior IDE, 5.9.0.3024, as supplied with M52259EVB and updated online to the latest version. The test code is a very small LED-flashing program which has been proven to work on the EVB.
First off, BDM programming has been very shaky, sometimes it works, sometimes it doesn't. The BDM is exactly the same as the EVB setup (with jumpers in default positions) and we're using a P&E_USB (Multilink) BDM module which we have proved works OK on the EVB's BDM port. We've managed a few successful erase/blank check/program/verify cycles but now it's given up and all we get when trying to start the programmer in CW is "Error: Initialization failed".
We are using the "MCF52259_INTFLASH.xml" config for the BDM module, as stated this works fine with the EVB's own 26-pin BDM port.
The board & micro now seem to be dead - even though the /RSTIN pin is pulled up, the /RSTOUT pin stays low permanently. We found CLKMOD1:0 was hovering around ~1.5v even though pulled up to 11 via 10k resistors. Pulling it up hard made no difference. Thinking the PLL may be causing problems we've pulled it down to 00 (MHz crystal oscillator bypass with PLL disabled) and still the oscillator doesn't start. It's now been restored to 11.
Hampering our efforts to understand what's wrong is the truly awful documentation for the BDM port, trying to work out which signals should be flying around from which end is proving very tricky. We can see the BDM module pull /RSTIN low for 20ms, three times, but then not much else happens. Any sortof signal/timing diagram for the BDM port would be greatly appreciated at this stage.
Sources of confusion are that the BDM seems to not want to work without a running oscillator on the board itself, and that even though the oscillator on our board is not running, there are some pins of the MCU which do have pulses coming out at low speeds (~3MHz, see below). Our oscillator circuit is the same as the EVB one so it's doubly annoying that it won't start.
I don't believe there is anything on our board which, in un-initialised state, could be causing any conflicts with the CPU in its un-initialised state (eg pulling legs high or low, etc.).
I'm not sure if any of this will help, but here's some pin states we've observed:
Powered up with no BDM connected:
/BKPT - 3v3
DSCLK - 3v3
DSI - 3v3
DSO - 0v
ALLPST - 0v
PSTCLK - 3MHz
JTAG_EN - 0v (pulled down)
FB_D3 - 60Hz low spikes (17ms at 3v3 / 190uS at ground)
FB_D2 - 60Hz low spikes (17ms at 3v3 / 190uS at ground)
VDDPLL - 3v3
EXTAL - 3v ish
XTAL - 0v
CLKMOD1 - 3V3 (pulled up)
CLKMOD0 - 3V3 (pulled up)
/RSTOUT - 0V
/RSTIN - 3V3
Powered up with BDM connected:
/BKPT - 0v
DSCLK - 0v
DSI - 0v
DSO - 0v
ALLPST - 0v
PSTCLK - 3MHz
JTAG_EN - 0v (pulled down)
FB_D3 - 60Hz low spikes (17ms at 3v3 / 190uS at ground)
FB_D2 - 60Hz low spikes (17ms at 3v3 / 190uS at ground)
EXTAL - ~3v
XTAL - 0v
CLKMOD1 - 3V3 (pulled up)
CLKMOD0 - 3V3 (pulled up)
/RSTOUT - 0V
/RSTIN - 3V3
Any light people may be able to shed on this would be greatly appreciated.
解決済! 解決策の投稿を見る。
Well we think we sorted this, kind of.
The clock issue was a layout mistake - EXTAL was being pulled up rather than XTAL.
Programming is still not satisfactory but it does seem to be working - the issue is that the flash programmer utility in CW does not properly initialise the BDM pod unless you quit it & re-open again in between attempts. So for example, if you had two boards to program you would have to program one, exit the app, re-open it and then program the 2nd board.
We picked this up from the logfiles - the first time you run an operation (erase, check, program, verify) it will initialise the pod, but if it fails it will not try again and just assume the BDM pod is in a working state.
Hello,
Did you try to use internal oscillator ?
CLKMOD0=0 (pud), CLKMOD1=0 (pud), XTAL=1 (10k pup resistor).
Don't forget XTAL pull-up when CLKMOD0=0 (figure 7-1 MCF52259RM).
When your soft runs, you can change the clock mode operation.
Regards,
Henri
It seems problems with the P&E USB are more common than I'd thought, quite a few on the P&E forum although they don't seem very good at answering things over there.
After changing the settings in Project -> Debugger -> Remote Debugging -> Connection Settings -> Edit Connection -> Log comminications data to log window we can now see that the BDM is not detecting a freeze condition on the micro, the log shows this from an attempt to connect & erase the flash:
P&E: set_bdm_shift_speed
P&E: Bdm Speed = 1
P&E: set_bdm_shift_speed
P&E: reset_hardware_interface
P&E: reset_hardware_interface
P&E: check_critical_error
P&E: criticalError = 0x00
P&E: check_critical_error
P&E: version
P&E: version = ColdFire Interface Libraries Version 3.25 (http://www.pemicro.com)
P&E: version
P&E: force_background_mode
P&E: force_background_mode = False
P&E: force_background_mode
P&E: force_background_mode
P&E: force_background_mode = False
P&E: force_background_mode
P&E: force_background_mode
P&E: force_background_mode = False
P&E: force_background_mode
Another time, when it didn't throw the "Initialization failed" error, it just kept repeating these three lines:
P&E: test_for_freeze
P&E: test_for_freeze = False
P&E: test_for_freeze
Well we think we sorted this, kind of.
The clock issue was a layout mistake - EXTAL was being pulled up rather than XTAL.
Programming is still not satisfactory but it does seem to be working - the issue is that the flash programmer utility in CW does not properly initialise the BDM pod unless you quit it & re-open again in between attempts. So for example, if you had two boards to program you would have to program one, exit the app, re-open it and then program the 2nd board.
We picked this up from the logfiles - the first time you run an operation (erase, check, program, verify) it will initialise the pod, but if it fails it will not try again and just assume the BDM pod is in a working state.
What kind of JTAG/BDM device we need for first programming of MCF52259 after it assembly assemble on board ?
Can we make first programming of MCF52259 by comm port bootloader ?
What kind of JTAG/BDM device we need for first programming of MCF52259 ?
Where we can buy it ?
FridgeFreezer wrote:Hi guys,
A few questions rolled into one post here, hopefully you can help us before the boss throws the board out of the window. Unfortunately my seat is in front of the window.
...
First off, BDM programming has been very shaky,
...
Any light people may be able to shed on this would be greatly appreciated.
We've seen "shaky" a lot.
Our BDM pod (P&E USB Coldfire Multilink) only works with SOME USB cables. By trial and error we've found a few cables that it likes, and lots that it doesn't.
Check your grounding. Add some VERY solid (and short) grounds from the proto to the power supply and the debug PC.
Concerning the bad prototype. Build a second one. You have to isolate Design problems from faults on a single board. You need another reference.
Is the chip a BGA? You might have some bad solder joints under the chip where you can't see them. Try flexing the board and see if anything changes.
If there are no faults, the board design IS NOT THE SAME as the EVB.
Manually check every net on the proto schematic against the EVB one. Twice at least.
Run the PCB design rules check again.
Manually compare every track on the PCB (in the design tool) against both schematics. You're looking for component pin-swaps or reversed pinout on something like a transistor.