XH-M188 locking up after power-up

[hexagon5un]

After a power cycle my test XH-M188s don't respond with the stm8eForth prompt, or apparently work at all. Sometimes a reset either with a pushbutton or the st-link programmer will bring the console back, but even then the PWM doesn't work. They work just fine when freshly programmed, but a subsequent power cycle kills 'em.

I wrote some frankly dodgy code in the init section for this board, and I'm not surprised if it's related to that. To set the hardware PWM channel for the board, there is some fooling around with option bytes in flash, and it could be the bug lies there.

I tested the same boards out with the MINDEV version, and they work just fine on power-up every time, so I'm pretty sure that it's the firmware. I'll look into it fairly soon.

[hexagon5un]

Fix was easy. Partly reading the three (!) datasheets correctly, partly buckling down and writing a one-liner busy-wait in assembly. Sent pull request.

[TG9541]

Great :-)
You might also want to have a look at this:

https://github.com/TG9541/stm8ef/blob/develop/lib/hw/opt.fs

and this:
https://gist.github.com/TG9541/321e58dd4c837bb3625d93bf845562f3

and finally this:
https://hackaday.io/project/16097-eforth-for-cheap-stm8s-gadgets/log/64582-native-code-in-forth-with-1-line-compiler-extensions

[TG9541]

I wonder whether a standard method for defining option bits in a project should look like. It would be possible to define option bits in a file in the board folder but especially for breakout boards that misses the point. Checking and setting the option bits should be done at the start of the application software. Problem is that options bits can be wrong even if the application is completely happy with the default.

What do you think about the following:

• always reset option bits to the default in the make flash target
• always check the option bits if a non-default value (i.e. not 0x00) is needed
• change the option bit value automatically if needed

[hexagon5un]

I didn't know there was option-byte code in lib/ ... or maybe there wasn't when I wrote the first versioin of the XH-M188 code.

The OPT! word in lib/ doesn't a) wait for EEPROM write to finish, or b) reset the option-protect bit (in FLASH_CR2) when it's done. It could probably do both.

An option-bytes config shouild definitely default to a per-board setting. On the XH-M188, for instance, it's absolutely necessary to set the option bit to enable PWM on the voltage-control channel.

And you'll definitely want to enable user access to the option bits for the general-purpose boards as well, as your servo example illustrates. OPT! is a great addition to the lib/.

The check-default, modify-if-needed plan you outlined seems fine to me.

[TG9541]

The library is quite new, and when you published the OPT-setting code the library didn't even exist :-)
You're right: the OPT! should reset the write protection bit. Please correct me if I'm wrong but in my understanding EEPROM and Flash write access stalls the CPU until the next write is possible. Since I don't know if it's safe to reset the option-protect bit before the write is complete it's probably best to wait until the EEPROM write has finished.
I'll change the OPT! library code (using an in-line STM8 spin-lock).