Need help developing a low level driver for SWIM

infoinfo9 · ‎2014-07-17

Posted on July 17, 2014 at 18:25

Dear STM08 Technical support

I am a consultant developing a flash programmer tool for the STM8 that runs on the Teradyne Test Station platform. The end users of this tool will be two high volume users of STM08 devices.

I have so far achieved only partial functionality of the SWIM debug module. And I need further advice to make it work.

My questions will reference document UM0470.

I don�t believe I have achieved successful completion of the eight step sequence described on page 10. I get to step 6 �Write 0A0h in the SWIM_CSR�. I assume at this point I need to do a WOTF 01 00 F7 80 A0. The STM08 returns an ACK for the WOTF command, and every data byte except for the A0 at the end. At this time the STM08 does not ACK or NACK, it simply floats high.

I do know that the SWIM is at least partially working because I get the first 5 ACK responses. I can induce a parity error, and I get a NACK. If I send an erroneous sequence like an SRST followed by a data byte I get neither NACK nor ACK. Somewhat predictable behavior.

If I simply ignore the final �failure to acknowledge� and proceed to release the reset, any subsequent WOTF commands behave pretty much the same way. An ROTF will reply with all of the correct ACK cycles, however the STM08 does respond to the command. No data is sent back by the STM08.

The device samples that I have are STM08F6266, de-soldered from PCBAs that were sampled to me from a 3rd party. I do not know if they are blank, or programmed, or if the SWIM access has somehow been locked out by firmware. Is this possible?

Other things that I have observed� The SWIM pin did not appear to have its own pull-up. I had to connect a pull-up to the SWIM pin, I used 5.1K. If not, when I got to step 4 of the entry sequence the STM08 would output a continuous low speed frequency instead of a single synchronization frame.

Any further advice that can help me make this work is much appreciated.

Thanks in advance for any information.

#swim

at1 · ‎2014-07-17

Posted on July 18, 2014 at 08:37

Hi,

I already built a SWIM Programmer too. It is hard to say anything without DSO prints.

Maybe you should start with a brand new µcontroller to be able to make sure statements.

I don't know the behaviour when write & read protection is active - I always used only read protection. Maybe your controller is write protected (or anything else I forgot) and does therefore not accept any data.

I also slightly remember that a delay between two commands should always be kept - otherwise my commands were not accepted too. I don't remember the exact behaviour and timing anymore but maybe you can simple try like 2-byte times between packets.

I don't know how your implementation looks like but I used STM32 and needed excessive use of assembler to manage timings. Also the delay between address-bytes and data-bytes may not be too long! I think I remember struggling with it because the delay needed to be (far?) less then one bit-time.

STM8 Devices have only weak pullup at Reset and SWIM. Manual says SWIM may sink up to 8mA. For good signal it is important to have external Pullup (I even use a current source to be voltage independent).

Best regards,

Alex

infoinfo9 · ‎2014-07-20

Posted on July 20, 2014 at 17:24

I am now seeing the exact same problem using STM8C207, unprogrammed samples from DigiKey. This time I attached a pdf with scope shots of the failure.

At this point I believe that the documentation is incorrect or maybe just my interpretation.

If anyone has a clue to offer, please let me know.

________________

Attachments :

Failure_of_SWIM_on_STM8S207_scope_shots.pdf : https://st--c.eu10.content.force.com/sfc/dist/version/download/?oid=00Db0000000YtG6&ids=0680X000006HzGu&d=%2Fa%2F0X0000000bKu%2FAw.AHJAJHh_olmIa5EQH7u5Tbo.ZOIfpO0lKLfFZrZA&asPdf=false

at1 · ‎2014-07-21

Posted on July 22, 2014 at 08:51

Hi,

I don't really have an idea now. Is your single Bit-Timing correct? Are you still using 5k resistor on SWIM? I'd suggest 680 R to get better slopes.

I cannot make dso shots of my implementation at the moment. You maybe should compare your protocol to one of the ST-Discovery. Maybe you see bigger or smaller differences.

best regards,

Alex

infoinfo9 · ‎2014-07-22

Posted on July 23, 2014 at 02:31

Thanks Alex,

The more aggressive pull-up has helped some, the SWIM will now ACK correctly after the last byte of the WOTF. Unfortunately my ROTF still returns no data. All ACK cycles are correct but the SWIM pin is stuck high at the end.

I will try some more tricks tomorrow, like stretch or squash the bit timing.

Thanks,

Dudley

zzdz2 · ‎2014-07-25

Posted on July 25, 2014 at 15:29

I am now seeing the exact same problem using STM8C207, unprogrammed samples from DigiKey. This time I attached a pdf with scope shots of the failure.

At this point I believe that the documentation is incorrect or maybe just my interpretation.

If anyone has a clue to offer, please let me know.

To me it looks like you are sending 0x40 instead of 0xa0 in the ''WOTF 01 00 F7 80 A0'' screen.

infoinfo9 · ‎2014-07-25

Posted on July 26, 2014 at 04:48

Knik,

I was probably expermenting with other values at the time I took the scope shot. But A0 produced the same results.

Dear STM08 Technical support

Since my last help request the only response that I received was a notice that my help request was being referred to another department and the suggestion that I get an ST-LINK/V2 and look at the signal patterns.

Since my initial request I did acquire an ST-LINK/V2 and some samples of the STM8S207CB.

I discovered that the STM8S207CB devices were displaying the exact same failure as the STM08F6266… When my tester did a WOTF 01 00 F7 80 A0 the SWIM failed to ACK or NACK after the last data byte.

A person on the forum suggested to me that I put a stronger pull-up, 680-ohms on the SWIM signal. I did this and it started to ACK for the last data byte, but only intermittently.

I then decided to reverse engineer the SWIM signals that my ST-LINK/V2 was producing. I noticed that the ST-LINK/V2 was not following the entry sequence shown in figure 5 of UM04 The ST-LINK/V2 was applying Square wave cycles that were 1.324MS and 662US, not 1.0ms and 500Us as the book suggests. I’m not sure if the book is wrong or what. I re-wrote the vectors that my tester (Teradyne TS124LH) was applying so they matched exactly what I was seeing from the ST-LINK/V2. I now seem to be getting a somewhat reliable ACK at the end of the last byte of WOTF. I could retry for this if needed.

The problem I now have is ROTF does not return any data. The last scope shot of the attached PDF shows this failure. Although the last scope shot only shows 60 US after the last ACK, I have waited for few seconds, but no data comes back.

Any further advice that can help me make this work is much appreciated.

Thanks in advance for any information.

Regards,

Dudley Hiller

Test Consultant

Uwharrie Test Solutions LLC

1527 White Smith Rd

Siler City, NC 27344

Mobile 303-818-3411

________________

Attachments :

Failure_of_SWIM_on_STM8S207_scope_shots.pdf : https://st--c.eu10.content.force.com/sfc/dist/version/download/?oid=00Db0000000YtG6&ids=0680X000006HtoS&d=%2Fa%2F0X0000000aXB%2FItTwZwmgKVBVASxthOP7iBkfZnqMkT9YdVa8vVFu0uY&asPdf=false

zzdz2 · ‎2014-07-26

Posted on July 26, 2014 at 12:19

Are you using push-pull output? Looks like transmission voltage is lower than ack input level.

infoinfo9 · ‎2014-07-26

Posted on July 26, 2014 at 17:08

Yes, my tester does drive it to 1, but Hi-Zs at the end of the bit time so the STM8 can take over. I don't have true open drain capability, but I have also tried driving behind a shottky to simulate that effect. That does not seem to make any difference.

infoinfo9 · ‎2014-07-27

Posted on July 27, 2014 at 18:13

Thanks all for the help.

I think I just hit pay dirt on the SWIM. I now get a successful ROTF with the data I'm expecting.

I reprogrammed my vectors to behave a little more like an open-drain driver. It still drives L-->H for a logic 1, but drives low then Hi-Z for a logic 0. That, in combination with a 680-ohm strong pull-up seems to be the magic I needed.

My next task will be to program and verify the flash. If I have trouble with that I will start another discussion.

Thank,

Dudley