We are running a survey to help us improve the experience for all of our members. If you see the survey appear, please take the time to tell us about your experience if you can.
I am using MDK-Lite Version: 5.11.0.0 with a ULink ME (V2.02) to develop code on an ADuc7021 32K part. I have two versions of hardware that have identical JTag circuitry with slightly differing processor IO. One board programs and verifies without problems, and the other fails with "Cannot Write to RAM for Flash Algorithms !" errors. The debug and RAM setup is correct for the device. I have searched for solutions, but the only guidance I can find suggests altering the debug and JTag setup or the device RAM settings which I know are correct. The problem can only be a hardware issue, but having compared the JTag on working and non-working boards, signal for signal, level for level, I have reached a point where I cannot progress further.
Do you know of any issues that would cause "Cannot Write to RAM for Flash Algorithms !" when all the RAM and debug settings are correct?
Regards, Kristin Hansen, Senior Development Engineer
You have multiple boards of design#2 ? And they are ALL failing in this manner?
If so you need to look more critically and the design differences, and enumerate them more precisely.
You could eliminate bad silicon issues by swapping working and non working chips across boards.
Pay attention to the readback/return path for the jtag scan chain.
Yes, ALL of them... which is why I am struggling to progress.
There are very few design differences: +1 x GPIO input, +5 x analogue inputs, +1 x Analogue output (all currently disconnected) +2 x GPIO outputs (P0.6, P0.7) -1 x GPIO output (P0.5)
The JTAG paths are via ~1cm of track and a 15cm debug header/loom to the ULINK.
I have scoped the JTAG lines and compared the two variants. The identification of the processor is identical, but the Flash erase request is aborted a short way into the message sequence in comparision to the working board. I haven't yet decoded the messages sent to see where it fails, but I think that's my next job.
The device itself is hard to rework (0.5mm pitch) and as these are prototype variants, I haven't boards to do another build run of the working design to determine if this is a processor silicon issue.
Thanks
Do you have any other JTAG test gear, can you do a boundary scan of the device. Sorry not intimately familiar with the AD family of devices.
Would double check schematic and PCB. Check pull-up resistors, and any potential cross-connectivity on the JTAG pins (TDI, TDO, TMS, RST, TCK, etc). Ground pads? Check an unpopulated board (solder test) for continuity.
Is your manufacturing group capable of X-Raying the board to look for under chip soldering issues?
Found it!
One of the new GPIO outputs (swapped from a DAC output on first prototype) was to activate a circuit to trigger Bootmode on reset. This wasn't immediately apparent as the Bootmode input pin was measured at high level when unprogrammed (default settings?). However, when #RST was triggered by JTAG, the bootmode input was held low for the duration of reset – hence entering Bootmode and stopping JTAG.
Definite Face-Palm moment.
Thanks for your help.