STM8AF Output NRST Pin signal

david.ye · ‎2018-04-10

Posted on April 11, 2018 at 05:58

Dear all,

First I would like to thank you for any help that you might give me.

My purpose is to flash an empty code in the uC (STM8AF5288TAY) but its always says ''lost SWIM communication''.

After analyse of our self designed board, I remarked that the problem might come from the NRST pin of the uC.

There is only a condensator connected to this pin during my test :

But you can see that the signal NRST(shown below) is not pulled up as it should be :

If I remove the condensator, I have this on the NRST pin :

Please can someone tell me why I have this signal in the NRST pin while there is nothing going on? In my undersanding I should have 5V straight while nothing is happening; So where this signal comes from?

I am really looking forward for an answer or advice as I can not find the solution since weeks and cannot flash any program.

Thank you in advance,

Ye David

#stm8 #nrst-pin #flash-writing

Max · ‎2018-04-11

Posted on April 11, 2018 at 20:29

Hello,

The datasheet specify the pull-up for around 40kOhm (see 10.3.7 Reset pin characteristics).

With the capacitor on the pin, we have a RC charge with a time constant of around 40kOhm x 10nF = 400us .

Am I wrong or this seems quite in line with the waveform you are observing?

Regarding your SWIM communication problem, you should look in your code and make sure the GPIO configuration of the SWIM pin is not modified, as this break the communication. This sometimes happens while configuring another pin.

Best regards,

Max

david.ye · ‎2018-04-11

Posted on April 12, 2018 at 05:01

Dear all,

Hello Max,

Thank you for the reply.

Indeed, the signal that we are observing correpond to the constant time for 10nF.

Nevertheless, the ''square signal'' is the source of the problem and in my understanding, changing the condo will not solve this problem. Here is the signal when we have 100nF condensator :

Normally, this NRST pin should always be at VDD,so 5v (when nothing is happening). I do not understand why there is a square signal instead. Is it trying to restart over and over?

To my understanding, having this square signal means that uC is constantly restarting; then flashing program is impossible.

Also, I do not think that the problem comes from the GPIO configuration because the code that I am trying to flash is empty !

Thank you in advance,

Regards,

Ye David

Max · ‎2018-04-12

Posted on April 12, 2018 at 11:23

Maybe an invalid instruction in the code. If an opcode is not recognized, a reset is generated.

Try with a working example to confirm.

This seems a bit fast but it could also be coming from the watchdog...

Select the software watchdog mode in the option byte to confirm.

In hardware mode, you must service it in your code to avoid a reset.

david.ye · ‎2018-04-12

Posted on April 12, 2018 at 12:32

Max,

Thank you for these advice.

The project that I try to flash is blank ! Not a single instruction. This is impossible to have an opcode error then, right?

Could you kindly send me a working example that I could try? The ones in stm8 website are several GB sized :\

As I never succed in flashing a code and seeing that reset value of the option byte of the IWDG_HW is 0, I assume that the uC is already in software watchdog mode.

Furthermore, if my NRST signal is constantly toggling, how is it possible to flash a program?

For information, this is the signal that I have when I am flashing a program with the stm8AL31 of one another board (SWIM in blue, NRST in red):

This problem seems to be very hard to solve, is there a possibility to be in contact with a STMicroelectronics developper of this uC? It has an important purpose for our company.

Thank you for your help,

Best regards,

Ye David

Max · ‎2018-04-12

Posted on April 12, 2018 at 13:17

If you don't put a valid code in the MCU, all you have is invalid opcodes everywhere in memory...

In other words, you must program something valid in the STM8, not just an empty program.

The SWIM interface was designed to be able operate when the device is under RESET.

I am sorry I don't have code to provide for this device.

But the

https://my.st.com/content/my_st_com/en/products/embedded-software/mcus-embedded-software/stm8-embedded-software/stsw-stm8069.license%3d1523530181920.html

is only a 12Mb package and contains many examples you can try.

If you want to get in touch with someone from ST, I recommend you contact your local FAE.

you can use

http://www.st.com/content/st_com/en/contact-us.html

to find a location close to you or ask your distributor.

raimond · ‎2018-04-12

Posted on April 12, 2018 at 18:59

Hi Max,

The SWIM interface does NOT operate when the device is under reset. There is only an 'entry' thing, but once it is done, the device must be released from reset. And that is the catch. If the device (cpu) performs a bad thing fast, it resets itself fast and you realize you don't have time to stall the cpu and begin the flash programming...

It is quite a bad design this SWIM interface. The swim controller should have been able to really run with the cpu under reset and be able to access the flash controller (at least) independently, and with the chip under reset. But these are dreams.

The reality is that you can brick the chip easily. ST gives a theory that you can catch a bricked chip with one in ten tryings... I don't know if it's true but I admit I managed to rescue some chips a couple of time with repeated tryings.

ST-Link dongles do a little trick: keeps the reset line low, and advices you to toggle the power in the mean time. And then, try again. Probably a power-on reset, with the reset line low already, helps.

For David: I'm afraid you have a bricked chip, one that resets itself very fast. You can try to program something on it with this procedure: use a ST-Link. When it advices you to toggle the power, do it. And keep trying programming it. If you are stubborn, you may succeed...

Something may be any valid program.

A valid C program for example is just this one:

void main(void) { while(1) {} }

Good luck!

david.ye · ‎2018-04-12

Posted on April 13, 2018 at 04:16

Dear all,

Hello Dragomir,

Thank to Max and you for the replies.

I tried fanatically to flash the code for half an hour but do not work.

>:(

This is the signal when the STlink tries to retablish the SWIM communication.

and the NRST pin at the same time/division

What do you mean by bricked chip? I already changed three time the chip and have the same results.

Do you know another way to force the chip to be flashed? Is this problem occurs lots of time?

Thank you for the help,

Best regards,

YE David

raimond · ‎2018-04-12

Posted on April 13, 2018 at 06:45

Never occured to me with new chips (but I only use STM8S variants).

I understand you program the chip under the IDE? Do the IDE advices you to toggle/cycle/turn off-turn on the power at any moment? If no, try the STVP ('ST Visual Programmer'). It's their original tool and I use it for such emergency problems. It looks ancient but it managed to rescue some chips for me.

Good luck!

david.ye · ‎2018-04-13

Posted on April 13, 2018 at 10:36

Dragomir,

-Yes, my IDE was asking me to reboot power supply and etc..

-Thank for the tip.

I downloaded the STVP and used the HEX file to flash the program.

Unfortunately, same problem occurs. The communication with the device is not possible :

The problem is that the Microchip is constantly toggling the NRST pin (screenshot are in the original post).

How can it be possible to still have this same issue knowing that I prepared the most simple circuit and with differents chip.

I am really looking forward to find the solution.

Thank in advance for the help,

YE David