Here we go again >> 9S08QGx programming problems

[irob]

Remember this thread of mine? Well, the ghost hasn't left me yet.

I just completed another small prototype run of 10 boards of a new assembly. Similar design, same MCU, used all the resistor/capacitor values I learned from the previous fiasco, er time.

And wouldn't you know it? Out of ten boards, 50% program, the rest don't. I've tried both my DEMO9S08QG8 background header and my P&E MultiLink BDM programmer. Same results.

Now it's back to the drawing board with value tweaking. I'm getting really bad feelings for this BDM interface. Sure, it's fast and I love debugging on the target board, but if getting into background mode is so precarious, what's the point?

[peg]

Hi Rob,

As your message came in I was reprogramming one of my GT16 boards that I mentioned in THAT thread. I still have never had ANY problems or flaky behaviour with my BDM interface with no pullups/pulldowns.

I also have made on stripboard what is a copy of Axioms DEMO9S08QG8 which has 10k pu with 0.1uF to gnd and 3k3 pu on BGND. It work flawlessly as well.

Actually now that I look at the circuit diagram it doesn't have the 10k pu on reset. Maybe I was listening to you!

Regards David

[irob]

Dave, you don't happen to have any QG4/8's yet do you? I'd love to see what others with this specific part are seeing. I've got maybe the simplest design using the chip -- the MCU, the RST and BKGD passives, bypass, an LED, and a connector. Not much can go wrong there!

I tried removing the RST pullup like you and Axiom have done. Now my MultiLink cable reports that instead of RST being stuck high, it's stuck low, even after multiple power cycles.

So bizarre!

[peg]

Hi Rob,

Yes I got a few samples. One is in my "DEMO" board. That is why I say it is working.

Regards David

[irob]

Dave, my 9S08 demo board works fine too. It's only my targets that have ever given me grief.

[peg]

Its not a genuine demoboard. Just a quite horrible lashup made on "veroboard" stripboard that is based on the circuit of the Axiom unit with no built in BDM of course. If anything should not work it should be this one.

[RockyRoad]

irob -

I know that you've already done a lot of investigation into this and it may not help to say "mine works," but you asked for other people's experience.

I have a breadboarded QG8 board here that has 10K pullups on reset and BKGD and a 0.1uF to VSS on reset. Like yours, it is also a simple board with just a BDM connector and all the pins brought out to headers. I don't have any problems with connecting to this board with either a Cyclone Pro or Multilink.

I don't know if this has anything to do with your problems so pardon a long winded explanation of something that may or may not have a bearing on your issues. On parts like the S08QGx that don't have a dedicated reset pin, there are problems getting into BDM mode when the flash is blank. During a normal power up with erased flash, the part is trying to execute without a good reset vector. It is going to try executing from $FFFF and immediately get into uninitialized registers. It more than likely quickly gets an illegal opcode or illegal address and resets. This process keeps repeating and there is no time for the BDM interface to grab control of the part.

On a part with a dedicated reset like the GT32, the BDM pod can grab control by simply pulling reset low. Since the reset pin on the QG4 defaults to a GPIO on POR, there is nothing that the pod can do with reset that will help with the blank flash case.

So, to initiate BDM communications with a blank QGx, the BDM pin must be held low during a POR. The debug interface in CodeWarrior asks you to do a POR with the pod connected if it can't establish communications. I haven't looked, but I assume that it is holding BDM low until you cycle power and click CONNECT.

- Rocky

[irob]

---

RockyRoad wrote:

Since the reset pin on the QG4 defaults to a GPIO on POR, there is nothing that the pod can do with reset that will help with the blank flash case.

So, to initiate BDM communications with a blank QGx, the BDM pin must be held low during a POR. The debug interface in CodeWarrior asks you to do a POR with the pod connected if it can't establish communications. I haven't looked, but I assume that it is holding BDM low until you cycle power and click CONNECT.

---

Rocky, very good thoughts. I had found that power cycling (using a bench power supply) with the MultiLink cable connected still wasn't connecting. So I tried something new with one of the blank boards. During the power cycle, I disconnected the plus lead to the target to make sure that the power was completely off (merely turning off the supply for a few seconds wasn't enough to let the board bypass dissipate?). Then I could get into BDM mode.

So your blank part theory seems to hold water. As a further test, once I had a programmed board, I observed that I could get in and out of BDM mode with no power cycling.

However, if I erased one of those programmed boards then started the process over again, I found that it was again a matter of clever power cycling to get back into BDM mode.

Still it seems strange to me how a few boards marginally seem to enter BDM mode even while blank, while others require power cycling.

Egads, the programming procedure I'm going to have to write for production! Makes me want to push for having preprogrammed chips assembled on the boards!