CAN Bootloader

[johu]

USART update fits in as well
3924 bytes
The protocol is unchanged so it will work with legacy wifi modules

I have reduced the transmitted page size back to 1k to stay compatible.

[davefiddes]

I'm afraid your CAN protocol needs some more work to handle the multiple device case. Without additional identifiers it's quite racey and prone to failures.

When two devices come up at roughly the same time your client responds to the first '3' packet it sees. What if this wasn't the correct board? If you put the ID in the initial '3' the updater can wait until it sees the correct board start then respond (or timeout). That way things proceed in lockstep with only one updater and board communicating and everyone else ignoring and moving on.

Also, I'd be wary of leaving the non-ID code in the bootloader and updater. Sounds like a license to brick boards.

[johu]

So you're saying if a node is late it will miss the magic packet and not go into update mode. Good point.

I could remove the non-ID code from the boot loader and leave it to the update script to just mirror back the first ID it sees. I certainly want a non-ID command because most setups will not have more than one OI board on the bus. Well, this is for the python script which I don't see a majority of people using.

The standard case should be an ESP32 module on the CAN bus. I think I'll put the relevant word of the processor serial in two places: an SDO object and a special line in the json output "serial": { "value": 0, "unit": "0=1234ABCD", ... }
Then the wifi module can obtain it and present a drop down with the serial number and perhaps the version string.

As always, sane node id assignment is instrumental for getting the CAN based comms to work.

[davefiddes]

Mirroring back on demand seems like a good compromise for systems where you know the topology.

I intend on implementing CAN updating as part of the openinverter_can_tool. My longer term vision is to be able to manage all aspects of an OI system over CAN. The Tesla M3 inverter sort of forces my hand in this regard.

[johu]

Same here, the BMS forces me And I think it will be quite neat not to have to juggle with multiple wifi modules anymore.

Currently doing the special SDO indexes for load, save, reset, obtain json

If you want to follow along, I'm on the master branch of libopeninv and testing in stm32-template. I have merged can_new_structure onto the master branch which separates CAN hardware abstraction and user protocols such as custom mapping and SDO.

The inverter is still on the float branch for the simple reason that it still uses the old message mapping structure. When going to the new structure (with more dynamic memory mapping, float gain and offset) it wouldn't be able to load messages anymore unless some converter is implemented.

[davefiddes]

Will have a look and see about adding support to oic. Was planning on working on load, save and reset commands soon but haven't started that this week. My code base has a different CAN framework for $reasons but it should be straight forward to adapt. Thanks.

[EV_Builder]

IMHO first package just should Tx it's ID. In that way you guarantee that only one device will respond to the correct ID later on with the magic byte. That's UpTo python GUI.

[johu]

Yes, that is how it's done now. It still contains the loader version number for future extensions and the ID in the last 4 bytes. It then only reacts if the updater responds with the correct ID

[davefiddes]

Just tried this code on my STM32 Bluepill based inverter. It doesn't seem to send anything out on the CAN bus at boot. The serial bootloader part works fine. I tried running the CAN bus at 800k as well as 500k. The CAN interface works fine when running the main firmware (5.24.R, master and new_can_module branches). I've not tried debugging it further.

[EV_Builder]

There are multiple CAN 0 pins. If I recall correctly the oi boards often use the af ones.

[johu]

It uses PA11 and PA12, the primary ones

[davefiddes]

That's odd. I definitely have those ones wired up.

[johu]

One difference between running the loader and stm32-sine is the clock source. Loader uses the internal oscillator which is less accurate (factory trimmed to 1% deviation). Could that cause trouble? Do you see any activity on a scope?

EDIT: actually UART would also look invalid if it were that...

[davefiddes]

Nothing on the CAN TX pin out of reset until I provoke it by sending an SDO request. Weirdly I can't connect to the device with my ST-Link v2 (clone) or official Nucleo-64 ST-Link. This *used* to work fine. I've had the board for years and it is a genuine STM32F103. Wonder if upgrading has splatted something important.

[EV_Builder]

"You provoke by sending sdo request?" How is that exactly?

[johu]

When you send 0x601 (assuming node id 1) you get a reply back

[EV_Builder]

Thought we talked bootloader?

[davefiddes]

I've found that erasing and flashing the bootloader via the USART boot ROM on the STM32 seems to improve things. I now get two CAN frames emitted to 0x7de as expected.

The can-updater.py has a problem. It sends out extended ID frames rather than standard ones. I found that sticking "is_extended_id=False," on each call to can.Message() was required to make it work. is_extended_id defaults to True and it's been like that since 2019 according to git-blame.

The serial upload on the bootloader doesn't seem to work well. I found I had to press the reset button after uploading on the web interface to get it to actually start the upgrade process. This did complete successfully though. Not analysed in depth but I wonder if it's a bit racey and perhaps relied on the watchdog resetting it previously to get enough "2" characters?

[johu]

Very odd all this.
Also noticed the extended frames but since it still worked I didn't dig deeper. Will add is_extended_id=False anyway.

With a valid firmware already present, the serial protocol sends a "reset\n" command which causes an immediate reset into the boot loader. So the resetting isn't part of the boot loader. It works well here. Any chance you try another board?

[davefiddes]

I don't know what's going on. Loading the regular bootloader back on and replacing with the CAN causes everything to behave itself. I'm now able to upgrade bootloaders and firmware via CAN or serial every time. Still no working SWD/ST-Link. Will get another Bluepill as the only other STM32 board I've got is a Nucleo which is too different to be useful. Sorry for any confusion.

I'd guess the extended CAN ID behaviour differences is probably down to the CAN adapter I'm using behaving differently from yours.