Problems getting a blank QG into background mode

[peg]

The QG, when blank, is very troublesome to get into active background mode.
I believe that the problem is not that it is blank, but that it has an unhandled COP.
A programmed device with an unhandled COP is just as troublesome.
A blank device when powered will reset itself every default COP period until you get it
into background mode.
This can be observed on a GB by scoping the reset pin.

This brings me to my first gripe.
The manual does not make it clear that even when enabled, the QG reset is input only!
Unlike most other devices, so you can't observe this on the QG.

Because of this resetting it is actually very easy to get a GB into BKGD mode.
Just hold reset low for at least the COP period and there you go!

Now it seems that as the QG has reset in only, this prevents the reset from getting
across to the BKGD module and so it doesn't work!

No problem you say! I will issue a "Background Debug Force Reset".
Well while this works normally, it DOES NOT work while the QG is in this mode.

It appears the only way to get a QG into active background mode while blank or COP
hiccuping is to hold BKGD low out of a POWER ON reset!

Now the P&E pod handles this by when it fails to connect it holds BKGD low and then
instructs you to cycle the power. The OSBDM has no such workaround and so you must hold
BKGD low yourself and cycle power then re-connect.

This brings me to my second gripe:
Why isn't an internal reset communicated to the BKGD module even if its not going out to the pin?

and my third one:
Why doesn't BKGD force reset work on a blank part?

Seems to me there is some issues in the silicon here

or in the manual?

or in my head?

or all three???

Regards
Peg

[RockyRoad]

Peg -

Let me try to answer all your questions, but come at them from a slightly different tack.

To me, the root of all the problems of trying to establish BDM communication with a blank QG part is the what you point out with the reset pin. In previous parts (like GB60), we had a dedicated, bidirectional reset pin. And as you noted, it is simply a matter of pulling reset on the pin while holding BKGD low and you're in active background.

But as we try to make lower pin count parts, the pressure is on to maintain general purpose I/O pins. In the case of QG, we chose to go ahead and add other functions to the reset pin. And those functions override the reset function. So you and I are stuck without an external reset on unprogrammed parts.

With a blank part, the CPU does not do anything different than if it were programmed. So it starts running from the reset vector out of POR. Because the part is blank and vectors all read as $FF, then it starts executing at $FFFF. The  instructions are then read as STX ,X; BRSET 0,00,0; ... (at FFFF, 0000, 0001...). So it is going to be 'executing' registers. This is going to continue until a COP, an illegal address, or an illegal opcode. With only 8K of program space, I'm betting that you get an illegal address before a COP, but I don't have a way to prove it. In any event, you're getting constant, frequent resets (that you can't externally observe).

The reason that Background Debug Force Reset doesn't work is that you can't get it written before a COP or other reset happens. (Reset does go to the BDM module.) The BDM communications rate is just too slow.

As for OSBDM, we did have an earlier design that used a relay for automatic power control to get around this problem. At that time, we only recognized it as a RS08KA2 problem, so it was part of the expanded design for RS08's. You can see the relay layout in the unused components on the pc board posted in the forum downloads. We have since abandoned the relay (expense), but the new OSBDM that Joerg is laying out will have a manual target power switch. So you'll get the same prompt as for the Multilink and switch the power yourself.

- Rocky

[peg]

Hi Rocky,

Thank You for your very informative reply.

However,

I made an error in my original post (3rd paragraph), To get a blank GB into BKGD mode you only need to hold BKGD low for at least one COP period.

This is because the GB is hicupping on the COP. The resets as visible on the RST pin correspond to the default COP period.

BTW, I did all my comparison testing with the RST pin of the the GB unconnected to make it similar to a QG.

You claim that reset is connected to the BDM, so why doesn't the COP reset get communicated to the BDM like it does on the GB. (irrespective of whether it goes out to an external pin.) If it in fact doesn't, why wasn't it designed this way? The manual rants on about a few extra transistors in the chip cost very little compared to full blown emulation, blah, blah. So why are we fitting relays to BDM pod designs?

I don't know whether you can write to BDFR in time on a GB either as doing a SYNC will cause the COP clock to stop as you will already be in BKGD mode due to the COP reset occuring during SYNC.

I have raised a service request on this as well, which I will report the result of back here.

I also raised one on the manual about the QG reset pin (in only) and it seems I was wrong and it is made quite clear. (I think I had too many manuals open at once in Acrobat).

Regards

Peg

[RockyRoad]

Hi Peg,

OK, so it was informative, but not helpful...

So I've done some more research and in finding answers, I understand a little better the operation that you've been been describing on the GB60. So hopefully, this will get closer to answering your questions. I don't know if they'll solve our frustration with the QG blank part, but maybe we'll understand why it's that way.

First off, the COP is handled differently in the GB and the QG. The GB was the first S08. It and the next part family (the S08Rxxx remote control parts) are the only parts that will switch to active background based on the BKGD pin low and a COP reset. (The connection is not really in the BDM, but that's a technicality.)

As we evolved the family, we realized that there was a possibility that the circuitry hanging on the BKGD pin, when it was being used for an external function, might have a large enough capacitive load to remain low during an internal reset. Even though a COP is bad, we didn't want to create a condition where the part would get hung in active background. So we limited the resets that will take you into active BDM to POR and BDFR.

And you're right. The price of enhancing the system security has pushed a problem out to the dev tools. We obviously didn't recognize the problem on the OSBDM when we first designed it. We anticipated it for RS08KA2, but not for all the other S08's that behave the same way. If we had, we probably would have put the relay on from the start since that was our mind set at the time for handling putting a part into active background.

BTW - Everyone else that I talked to agreed that the QG is rapidly getting illegal address resets long before a COP and gives no chance for a BDM command to get in. (There are no illegal addresses on a GB60.)

Best regards

Rocky

[peg]

Hi Rocky,

Gee, still not being very helpful, are you?

No, thanks very much for the info!

Now it pretty much all makes sense, I knew there had to be a difference. What I didn't know was that it was DELIBERATE!

I have been delving into this as I have been assisting Gabriel Dubatti with his BDMLoader project. I have been pounding my head against a wall for a long time trying to work out why I couldn't get into a blank QG part when I realised that it didn't work real well on all the other designs as well.

The BDMLoader only uses an overclocked QT1, 2 x FET's and 2 x resistors, so putting a relay in is a big hit. I think I will just use P&E's method of holding down BKGD on entry failure and waiting for a POR. I was really hoping for a more elegant solution.

Of course this is normally only an issue with virgin parts, normally the only time you erase a part is to put something else in, and as long as you do this straight away there is no problem. This does pose a problem for newbies though!

Thank you very much,

Regards

Peg

[irob]

---

peg wrote:

I have been pounding my head against a wall for a long time trying to work out why I couldn't get into a blank QG part

Well, it's about time! Sorry, Peg, but karma had to get you eventually. I'm just glad to see that it's not only me for a change who's been fighting this issue.

What I'm not seeing here is a real tangible workaround. Are we saying that the P&E programmers with relay power control (like the Cyclone) is the solution over using the non-relay programmers (like Multilink)? What I need the most is to figure out how my production floor is going to program blank boards without calling me in for help!

Oh, also, what's this OSBDM you're talking about?

[OldMan]

You do not need a "relay". You only need to be able to turn on/off the power to the QB8/4 chip. You can use a transister, a FET, or a voltage regulator with a shut-down control pin.

Yes, the P&E USB BDM that is part of the DEMO9S08QG8 works fine. 

[irob]

Hmm, well it's been my experience that manually removing power to the target isn't a guarantee that it will enter background mode. It can take a few power cycles to get it to cooperate. And for whatever reason, some chips are more ornery than others, absolutely refusing to enter background mode.

[peg]

Hi Rob,

I,m glad my tales of woe have been able to make you feel better! At least they were not completely in vain.

Most of my frustration was just trying to understand why, because I didn't believe that it would really be deliberately built this way.

Powering up with BKGD low works every time for me!

Hi Oldman,

I have a circuit for the DEMO9S08QG8 manufactured by Axiom in front of me. The P&E BDM section is "black boxed" as usual.

I have my doubts that the BDM controls the power to the device. Are you sure about this?

If it did then this board sans IC would be a better BDM for the QG than the real thing.

According to the schematic this would only be possible using the USB as the power source for the QG.

The reason I doubt it is there is at least 110uF on the "switched" side of the power supply which would make it seem unlikely.

This board allows the power supply to be taken from USB or a jack or pin 1 of the 32 pin header, the last two sources are hard wired (via jumpers) to the device Vdd.

I will have a more detailed look at your post later when I have more time.

Regards

Peg

[OldMan]

Hi Rob,

a) Manually remove power.

b) Manually hold BKGD pin low.

c) Restore power while still holding BKGD pin low.

d) Release BKGN pin.

f) Let BMD tool handle the rest.

Hi Peg,

You are right about power sources. I was using “USB power” (VB), which originated from the P&E USB BDM part of the DEMO board. Only this power source can be controlled by the PC software and P&E hardware.

Yes, I am quite sure that CW5.1 S08 Special Edition does turn off/on this power source when necessary. However, details of point (4) in my reply #7 were not quite correct. Here is my updated observation:

(a) RESET pin is never used.

(b) Normally, only BKGD pin is used to communicate with the chip and VB power is always on.

(c) When BKGD pin fails to communicate with the chip, CW drives BKGD low and turns the VB power off. (The green “USB” LED will stay on. The amber “OUT USB PWR” LED will turn off. The green “VDD” LED will also turn off.)

(d) After a delay of ~400msec, VB power is turned back on, but BKGD stays low for another ~36msec.

(e) BKGD is high and after another delay of ~5msec it is used to communicate with the chip again.

[peg]

Hi Oldman,

Well it certainly seems as though you are correct!

These LED's you are talking about are in the BDM section of the board, are they?

Another reason I was doubtful was that presumably CW is not told that it has a DEMOQG8 board attached rather than a normal USB BDM connected to a QG8 on some other board. So how does it know to suddenly start controlling the Vdd.

I am thinking now that perhaps the now useless RESET signal is just converted to power switching.

If this is the case maybe an adapter can be made for a "normal" USB BDM. Just an adapter that goes in series with the 6-way lead that converts the reset line into a power switch???

Hmm needs more investigation.

Regards

Peg

[OldMan]

Peg,

I think RESET pin of the BDM connector is used for supply of programming power to RS08 chips.

I ordered a DEMO board for RS08. I will post my findings soon.

Regards,

OldMan 

[OldMan]

Peg,

I received the DEMO9RS08KA2. It is made by SofTec Microsystems. The schematic is complete and include the details of the USB BDM interface. If you want, I can send you via private e-mail, but I think you can get it directly too.

They use a MC9JB16FA chip to implement the USB BDM. They can turn off the power to the RS08KA2 chip, and they can change the voltage level of the RESET pin from 3.3V to 12V. (Like I said, they did all these using FET, not relays.)

Regards

OldMan

[irob]

Just as a note, I used a microprocessor reset monitor chip to handle the background line conditioning out of power up.  Works very nicely and it's an off-the-shelf solution (no extra timing needed).

I used the Microchip MCP120-270DI/TO, which is an active-low open-drain output, no internal pullup, typical reset hold of 350ms.  My programming platform is very reliable now.


Message Edited by irob on 2007-09-21 02:48 PM

[RogerSchaefer]

Hello irob,

I tried your idea of the using the MCP120-270DI/TO reset monitor chip and it did the job but what I didn't understand is that it can be used only for a programming platform. 

I put the reset chip on my target board and it prevented the application program from running ( don't understany why that is ).  So the approach works but only on a programming board.

Roger Schaefer

[peg]

Hi Roger,

Rob's idea here is to use a reset device on the BKGD pin to hold it low for longer after power up than the reset is internally held low for on power up. This will force the chip into background mode on EVERY power up. This works well on a programming board but NOT for an application board.

Background mode is entered by releasing reset while BKGD is still low.
Normal mode is entered by releasing reset with BKGD high.
Reset is held low for a short time after reset. This assists in entering normal mode with nothing connected to BKGD (the normal case in application).

[RogerSchaefer]

Thanks for the background info on background debug, Peg.

I connected the reset line thru a jumper shunt and that took care of that problem.

Now I have to figure out how to calculate the trim and how to program it into $FFAF.  CW wants to erase the whole chip every time I load my program.  But that should be the subject of a new thread.

Roger

[peg]

Or see here for a current discussion on this subject.

[irob]

Roger, I'm glad to hear the reset chip worked for you.  The reason why your program code isn't running is that the reset chip (which is attached to the BKGD pin) is putting the HCS08 into background debug mode.

For normal operation program code, the BKGD pin has to come up at the same time (I believe) as RST.

Can you disable that connection between BKGD and the reset chip temporarily?  That should solve your problem.

[peg]

Hi all,

Here is the response to this from Freescale Support:

This issue, as you already know, happens with new parts and in some cases with parts, especially when you are not using the reset line to control the MCU reset with a Multilink or any other tool or communication used; also, it has a "logic" explanation to say it in a way.

Starting with the parts that have never been programmed and keeping in mind that the programmer can't reset the MCU, when the MCU detects a reset it goes and take the contents of address 0xFFFE (reset vector), which in your case is 0xFFFF (blank state). Then the program counter goes to address 0xFFFF and takes the contents of this address as the first instruction, in this case again, 0xFF which is a STX ,X instruction. After this, the MCU keeps executing code from the area where the registers are located, and some of these registers are the contents of the ports and this can lead to random execution. What can happen here is "random" because you don't know the contents of all the registers and the data that is in RAM and it can go from an Invalid Operation Code to change the contents of a register and so on. Since the BKGD pin is multiplexed with a PTA pin, it might be possible that you are disabling the BKGD pin and that is why you can't go to background mode anymore. When the programmer can control the reset line, it can send a low state to the reset line and ensure that the BKGD pin is low when the reset goes high; by doing this the MCU will always go to an active BDM mode. In your case you don't have control in the reset line and I think that is why you can't execute a Background command and force the MCU into active BDM mode. When you already have a programmed part this is no problem because you know that the code executed by the MCU won't be random.

The watchdog case might be very similar. You need to execute a background command to enter to background mode but this is not done immediately after reset; it takes some time and depending on the communication it might be that the watchdog is causing a reset before the background mode goes active by the execution of a background command. In many cases, the BDM communication starts with a SYNC command, but this is not directly a BDM command meaning that this is a "handshake" between the host and the device to start the communication at the proper rate. Since the background mode is not enabled when this SYNC starts, it takes a little more than 128 cycles of the internal reference divided by 64 plus the time needed to start this SYNC. This might lead to the device to reset before executing a BDM command and you will have to start over again.

About your question regarding the BDFR bit, you have to remember that this bit has to be written using a background command; we go back to the same explanation, if the background mode never goes active, it is not possible to use this bit. Any attempt to write it from user's code will be ignored.

Normally when you don't have anything plugged to the MCU it works fine and you are able to program it (this is why it usually works with some Demo boards and then you are not able to do the same on your HW). Other option is trying to ensure that the BKGD pin is low at the rising edge of reset; if you are using a multilink normally it works having the multilink enabled and connected to the board when the power source is enabled (meaning that the multilink will be driving the BKGD pin low when the MCU is powered-up and this will go to active background mode).

However, the must secure way is to already have the part programmed when you put it in your board, knowing that this is very complicated when using surface mount parts (like SOIC packages). In the case of some distributors, they can sell you parts that come with some code from the factory, so this can help you to fix this issue.

I hope that this information clarifies the problem. Please feel free to contact us if you have further questions. Should you need to contact us with regard to this message, please see the notes below.

Best Regards,

Rafael

So it seems I was right in the beginning, it is just difficult.

Regards

Peg

[OldMan]

Hi,

I am a newby and only have a DEMO9S08QG8 kit, so my knowledge is very limited. But here is my take.

(1) According to the QG8/QG4 datasheet Section 3.4, the PTA4/ACMPO/BKGD/MS pin acts as MS during POR. If the BDM tool holds this pin low while the QG8/QG4 chip powers up, the chip will enter active background mode. Thus the reset vector at 0xFFFE is ignored and should not cause any problem.

(2) The DEMO board comes with a built-in USB BDM from P&E. It is capable of controlling the power of the QG8 chip. It does not have any “relay”, but there may be a transistor or FET to do so. I do not have the schematic of this part of the DEMO board.

(3) CW 5.1 special edition that came with the DEMO board does use the power control capability of the P&E DBM described in (2) above. However, it does not use the procedure as described in (1) above.

(4) My observations are described below.

a) The Reset pin (pin 4 of the BDM connector) is never used.

b) Normally, Pwr (pin 6 of the BDM connector) is always on. Only BKGD (pin 1 of BDM connector) is used for communication between CW debugger and the QG8 chip.

c) If this communication fails, CW will turn off Pwr for ~440msec but BKGD remains high.

d) After Pwr is back on, BKGD stays high for another ~5.4msec.

e) After that, CW drives BKGD to low for ~10.8msec.

f) Hopefully, communication is re-established after this.

(5) My opinion is: CW debugger should have driven BKGD low when it turns the QG8 Pwr back on. This way, the chip will always power-up to active background mode irrespective of the contents of the Flash.

(6) My worry is: if the code intentionally or unintentionally disabled the BKGD pin or the ICSLCLK ***shortly*** after POR, the current CW debugger will never be able to force the chip to active background mode.