Thank you for the fast reply!

My chips are:

STM8AF6166TC

Hope that helps you.

I tried the deactivation of the DeviceID.
Now connecting, erasing and programming is possible.
But verify fails:

(5) Verifying flash against file myHex.hex ...
!!! Error 304: Communication error: Timeout error reading on USB: WDU_T
ransfer() failed: error 0x20000002 ("Invalid pipe number")

Any idea?

Hi,

Does the program run? That would tell us if the problem is in the programming or in the verifying.

Please tell me the version of the Ride7 and RKit-STM8 kits that you are using. You can see that by clicking help->About in Ride or RFlasher.

Also, isn't there anything else written on the chip?
On mine I see this:

STM8AF
51A8TC
991EC V6
MYS 802

Best Regards,

Vincent

Yes, the program is running.
Verifying or BlankCheck fails.

Ride7 version: 7.22.09.0203
R-Kit version: 2.22.09.0203

Chip:

STM8AF
6166TC
9917G VG
MYS 849
(e4) Y

Hi,

Thanks for the information.

I asked ST to send me some devices like yours, but I will not be able to use them before the second week of August. (I'm on vacation next week) Then I can check the software and correct it. Can you work without the verification until then?

Can you please tell me if the different programming operations work in RFlasher?

Best Regards,

Vincent

Yes, it doesn't matter, if you need one week more.

With RFlasher Erase and Program works, but BlankCheck and Verify fails with the same error message as in command line mode.

Hi,

In fact your verification problem is not special to this chip, so I could reproduce it and make a patch that solves it. You will find more information here:
http://raisonance-forum.xsalto.com/viewtopic.php?pid=9978#p9978

Please let us know if it solves your problem. You need to keep your modified config file, as the patch does NOT solve your first Die ID check problem that IS specific to your device.

Best Regards,

Vincent

Yes, it seems that everything works fine now.

Thank you for your help!

The patch is also available on the download page. It is specific to the latest RKit-ST7-STM8 release.

Hello,

it seems to me that verifying is not working well.

I want to verify my device in this way:

STM8_pgm.exe TSTM8AF616 R E B FProgramCode.hex VProgramCode.hex FData.hex VData.hex FOptionBytes.hex

In this case the flasher sais (two times): "Flash content matches file."

If I do the following with an EMPTY hex-file to verify, the same message appears!

STM8_pgm.exe TSTM8AF616 R E B FProgramCode.hex VEmpty.hex FData.hex VEmpty.hex FOptionBytes.hex

So it seems to me that verify does not work correctly.
Do you think that the patch could be the problem? Is this fixed in the next version?
Or am I doing something wrong in the usage of the tool?

Thank you!

Hi,

The Verify command checks that the data referenced by your hex file is the same in the Flash. It does not check anything concerning the memory addresses that are not referenced in the file. (If it did, your second check would always fail ;) ) So verifying against an empty file is the same as doing nothing.

If you want to check the Verify command, I suggest you duplicate one of your hex files, exchange two bytes on one same line of the copy (to avoid checksum issues) and run your command using the original for programming and the modified copy for verifying. Then the program should see the difference.

If you want to verify the unused parts of the memory, then you just have to create a hex file that references the whole memory. You can do that easily with the Save command of RFlasher: open RFlasher, select your derivative, load your hex file to RFlasher's memory using the "Load File" command, and then save the whole range that you want to verify into another hex file using the Save command (right-click in the data dump view). Then, use this file for verifying. (and also for programming if you want)

I hope it helps.

Best Regards,

Vincent

Ok, thank you. It seems that it works now ;-)

One last question:

Is there the possibility to get a return value from STM8_pgm (pass / fail)?

Hi,

Yes, STM8_pgm returns an error code in the standard way:
errorlevel = 0 means "success"
errorlevel != 0 means "failure - see text output for more information"

So you can write for example a batch file like this:

  STM8_pgm.exe TSTM8AF616 R E B FProgramCode.hex VProgramCode.hex FData.hex VData.hex FOptionBytes.hex
  if errorlevel 1 goto stm8pgmerror
  echo !!! SUCCESS !!!
  goto stm8pgmend
:stm8pgmerror
  echo !!! ERROR !!! see detailed error messages above
  pause
:stm8pgmend

I hope it helps.

Best Regards,

Vincent

Fine! Thank you for your support!

Sorry for asking again....

But it seems to me that I can't program all option bytes of the STM8A.

Writing to address 0x4810...0x4817 and 0x487E...0x487F does not have any effect. The memory is still 0x00 after programming.

Writing to 0x4800...0x48E0 seems to work properly.

Any idea?

Hi,

Indeed there is a problem here. Thanks for reporting it. I designed the software using a draft of the STM8 spec that did not mention any option byte after 0x480E, but when looking at the latest version of the spec, I see that there are some up to 0x487F.

I will fix that for the next release of the STM8 kit. In the meantime, as a temp fix, you just need to edit the "STM8_SWIM_ProductInfo.txt" file (again) and change the value of the "OptionBytesSeg_Size" attribute from 0x0F to 0x80. Only change the first occurrence of the value.

Many thanks again for your patience.

Best Regards,

Vincent