USB BDM NT

[antus]

Does anyone have experience with attempting to develop BDM definitions? I got lucky hitting read and managed to pull what looks like a single correct copy of the corrupted flash on my E54 but I cannot make it do it again. I don't know if I am hitting a problem with mis-configuration of the PCM, or an electrical problem with a missing or incorrect BDM line and would be interested to see if anyone can suggest one or the other with the symptoms.

The one time only read bin is attached, the screen shots shows a bad read. Each re-read the data patterns looks similar but are different.

I have a feeling a missing control connection or similar between the BDM and the CPU might cause this and the good read was just lucky timing when the CPU was in the right state and the CPU was stopped with FREEZE. If anyone can confirm this is likely i'll continue to focus more on hardware, not software.

That valid read data came out that one lucky time tells me I must be close.

[antus]

update: It appears to be my in development E54 config file for USBBDMNT. If I hit init, then read really quickly I get a valid bin about 1 in 4 attempts. If I init then wait a couple of seconds, then hit read, I never get a good bin. I think the watchdog is running and i've got to move quick (as well as other problems with it). Work continues. Can't get a valid chip ID, no chance to write and recover it yet.

[antus]

Found write byte 00 to 0xFFFA21 for disable COP on E54. Getting reliable reads on BDM now. I think that configuration register is probably the same as all of them, though seems to default to off instead of on, for the others i've looked at so far. Still cant set command mode for chip id, though.

[darkman5001]

I am watching this closely Antus. I have been trying to understand the ins and outs of USB JTAG and BDM, and I am hoping someone comes along with some answers.

[antus]

OK. First part is electrical. Many of these pcms have the same header grid at the edge of the pcb, and that follows a standard so for E54 I used the P08 connections earlier the thread (but swapped black and brown as they're backards in that pic.. though it works as shown too - ill fix that later).

Then for the config file its like peek and poke to you need to write 1 2 or 4 byte config data in to registers to init the platform enough the cpu can talk to the flash, and then config the platform like the flash kernel does to at least get the flash in to command mode, better if you can get vpp to turn on, else vpp can be connected in hardware.

So to do this you dissassemble the OS and look at what its doing at boot time. The SIM registers do most the platform config, so for example in E54 at boot it writes FFFA00 to register a0 then it uses syntax like 15(a0) to write in to the SIM at address FFFA15. Then you start putting .b (1) .w (2) or .l (4) byte writes in to the config file and testing over and over until you get flash read which means your flash interface is up and running or chip id meaning its in command mode.

[antus]

Sometimes the OS will use and, or, bset or bclr instructions to manipulate SIM registers, but USB BDM NT cant do that, only write values but it is also like a terminal so you can do peek FFFA12 (for example) to see whats in there from cold boot, then modify that value as the OS would, and then just put the whole value in the BDM config file.

The sort of stuff you are doing with these values (known as inits in the config file) is disable watchdogs, setting the ports on the cpu to input or output, maybe voltages etc. The same sort of things you might know if youve ever written arduino code to setup the cpu and get the gpios working.

There is some information about the SIMs in the documentation from motorola posted elsewhere on the site, but to be honest half of it is just a copy of values and addresses from the PCM bin boot code and educated guesswork. I couldnt tell you what most of the inits in my E54 config so far are doing, and most of them probably are configuring things that are not needed but its a better use of time to just reproduce the same writes as the init code in the PCM.

But to spell out finding watchdog enable bit:

SIM SYPCR System Protection Control Software Watchdog aka Comput Operating Properly COP.jpg (100.36 KiB) Viewed 819 times

SIM SYPCR System Protection Control SWE bit.jpg (201.32 KiB) Viewed 818 times

e54 init code in the OS boot sector.png (82.77 KiB) Viewed 817 times

c5sim.pdf

(877.18 KiB) Downloaded 37 times

apdreg.pdf

(733.86 KiB) Downloaded 40 times

Note that SYPCR is actually at SIM Base + 20, but the factory only writes a single byte in to SIM Base + 21 as the data sheet shows half of it is unused to set the used half the register, and I adapted that register in my E54 config file to write 0 in the same way to disable COP and get the flash read working reliably. Thats why datasheet has $YFFA20 and the factory disassembly and register description use a byte in FFFA21.

Note that bits are 0 to 7 from the right hand side, and 9C is 1001 1100. So that first 1 enables the software watchdog, and setting it to 0 turns it off.

[antus]

Its great writing this up. Has given me some more ideas for later. I wonder if I can use USB BDM NT to talk to a PCM without sending reset? If so it might be possible to poke 00 in to FFFA21 to disable COP and then freeze it in its fully booted state and then run a script that just reads down the SIM registers and gets all the normally running values, then write a script that puts them all in to a new config file. Then that could be used on nearly any PCM in this family to create a new config file for BDM flashes that can get the hardware up to the same state it is in from a full boot pass to kernel without needing to do the spelunking through disassembly. Maybe someone could investigate that one and write such tools. If there are any PCMs in the family left people are still interested in I guess. Through would apply to any PCM or even most embedded hardware with an M68k and BDM accessible.

Actually I just noticed you can only write the SWE bit once, so it'd need to be patched in the bootloader and os checksum updated and written back in to the PCM.

[DWS]

I didn't read all the new messages, but the definitions I'm pretty sure were mostly around the flash chips If I remember right, unless I'm thinking of a different definition area.

You have some "command line" tools to use within the software too, peek/poke are a couple, a reset would put it back to effectively the initial power on state and pause it at the boot loader section of the code. If you step through the program you can track the bootup process. You can tell it to step like 1000 commands too so anything timing related can be done within a normal window too (knowing the exact number is a bit more tricky). Once it's in the main operating loop, you can do some interesting stuff.

It's been ages since I was messing around this stuff, but I think the software let you run effectively macros where it's like typing the commands in but it would process them one right after the other (maybe that's what I was dreaming of when using the program though? don't remember lol). Either case it should be possible to step the correct number of times where you pause/freeze it right at the first command of the main operating loop, change memory/ram address values as desired, then let it continue to run like normal.

Last time I was poking around within that program I was running windows and was poking around at a P04 GM computer. I remember I was wishing for some sort of script/program api interface since I had all kinds of ideas floating around my head.

Also remember, you can change the program counter/pointer value, so you can pause the boot up script right at the line t hat writes the SWE bit and skip it if desired. The exact number of steps might be different for different boot loaders though, it would be neat if there was a way to script things where the actual next command could be checked if it's a target command or not, and freeze the program on that line sort of like a break when running a program in a debug mode. I suspect it probably is possible, just not sure if it's possible within the USB BDM NT software.

Another thing I remember was you can update the program pointer to code in RAM, so in theory you should be able to write custom code in ram, then execute it as needed as long as the memory values don't get overwrote. Might not be true for all processors, but the P04 one I'm pretty sure worked that way. At bootup, you have the full ram space to use, not sure if there's any initial setup that's 100% required before hand though.

I basically used the BDM to step through the boot loader to try to learn a bit more about the initial setup of the computer/hardware, but at the time I didn't really know a whole lot about computers at that level (still quite new), I learned a ton from the process though.


On the flash dump side of things, it probably wouldn't be too hard to write a script to auto patch to disable the watch dog since you know how it's enabled and it looks like you found an example of code setting it. Probably the easiest way to disable the watch dog I'd assume.

If I remember right reading/writing the flash chip might have required defining the watch dog stuff if it was enable. I'm really fuzzy on the details around that though. This stuff was my first real touch of hardware hacking of any capacity.

Oh I also remember powering up the computers early on and freezing it at a random spot in the operating loop, I don't think the reset is required when you're effectively doing the debug stuff in the main window.

Anyway, not sure if any of this is useful, but it should be possible to do quite a lot via the BDM interface directly. Good luck with the project.

[antus]

Yep all of that is correct. It's just getting the register writes correct to enable the right outputs on the CPU, and even better if you can turn on the VPP signal to an intel chip. For reasons unknown I have not been able to get it to put the flash chip in to command mode to get the IDs. I can read the contents OK. Its a little bit odd because its a sequence of reads with magic numbers and addresses that should do it so if I can read the contents I should be able to read the chip id. I am pokeing all of the boot configuration values in to the SIM registers, but no luck yet.

Come to think of it, I am getting an erroneous FF on the first read, Infront of the flash image, then the next read works. I was discounting that oddity for now but in hindsight I bet that is something to do with the problem reading chip id. I just don't know what could cause that to happen.