Problems flashing co-processor on balenaFin V1.1 (via. Raspbian)

mad.dove · September 25, 2019, 10:06am

I’m trying to flash the co-processor from Raspbian using openocd. I have basically executed all steps that this balena application does, when it is run on balenaOS:

https://github.com/balena-io-playground/balena-fin-firmata-flash

I’m now at a point where uart1 is up and running and I should be able to just run flash.sh. However, when running flash.sh it complains about pin 510 (export error) from the “/co-processor/app/openocd/config/balena-fin-v1.1.cfg” file. If I comment out “sysfsgpio_srst_num 510” in that file, the whole flashing process executes fine, with the following output:

./flash.sh firmata-balena-0.0.2.hex 10
Opening screen terminal for flashing firmata-balena-0.0.2.hex to balenaFin v10
Trying ::1…
Trying 127.0.0.1…
Connected to localhost.
Escape character is ‘^]’.
Open On-Chip Debugger
reset halt
target halted due to debug-request, current mode: Thread
xPSR: 0x01000000 pc: 0x0fe10000 msp: 0x20000400
program firmware/bootloader.s37
target halted due to debug-request, current mode: Thread
xPSR: 0x01000000 pc: 0x0fe10000 msp: 0x20000400
** Programming Started **
detected part: EFR32MG1B Blue Gecko, rev 151
flash size = 256kbytes
flash page size = 2048bytes
Padding image section 0 at 0x00000614 with 492 bytes
** Programming Finished **
reset halt
target halted due to debug-request, current mode: Thread
xPSR: 0x01000000 pc: 0x0fe10000 msp: 0x20000400
program firmware/firmata-balena-0.0.2.hex
target halted due to debug-request, current mode: Thread
xPSR: 0x01000000 pc: 0x0fe10000 msp: 0x20000400
** Programming Started **
** Programming Finished **
reset run
Connection closed by foreign host.
closing the openocd process…
flashing complete

However, after doing so, the co-processor is not responding when I send firmware version requests ([0xF0, 0x0B, 0x00, 0xF7]) over the uart1 serial line. I’m therefore thinking the flash probably wasn’t successfull and needs the sysfsgpio_srst_num 510 pin to succeed, which I commented out. I therefore have two questions:

From the output listed above, does it look like the flashing of the co-processor succeeded?
If not, do you have an comments to why “sysfsgpio_srst_num 510” in the openocd config file, would throw an error (could not be exported)? And any recommendations in general?

Thanks in advance!
Mads

curcuz · September 25, 2019, 2:58pm

Hi @mads GPIO 510 is a GPIO pin exposed by the i2c I/O expander on the Fin and is connected to the reset pin on the co-processor. It is required for a successful flash and support for it is added to both balenaOS and our raspbian images with a kernel module and the usual balena-fin overlay. Are you running our maintained version of raspbian, and are you setting up the balena-fin overlay in config.txt?

mad.dove · September 25, 2019, 7:19pm

Hi curcuz,

Thanks for the quick response. Good to hear that there’s a good explanation to why it’s not working for me then. I’m running your Raspbian version from 26-02-2019 yes. This automatically had the:

dtoverlay=balena-fin-updated

entry in the config.txt file. I then manually added the uart1 setting below that, so the config.txt now shows:

dtoverlay=balena-fin-updated
dtoverlay=uart1,txd1_pin=32,rxd1_pin=33

Is this also what you would expect config.txt to have for it to work?

curcuz · September 25, 2019, 8:28pm

Hi @mad.dove your configuration looks correct to me. What happens if you try to control the pin manually via the sysfs class?

echo 510 > /sys/class/gpio/export
echo "out" > /sys/class/gpio/gpio510/direction

curcuz · September 25, 2019, 8:38pm

@mad.dove I might have figured it out. You need to enable i2c via raspi-config -> interfaces - can you please try that?

curcuz · September 25, 2019, 8:55pm

update: I went ahead and set up a raspbian test case. Managed to reproduce. after enabling i2c via raspi-config or manually editing config.txt, there is still a problem with the I/O expander driver (pca9554) not being loaded. We are looking into this

curcuz · September 25, 2019, 10:17pm

progress on the issue will be tracked here https://github.com/balena-os/pi-gen/issues/6

mad.dove · September 26, 2019, 7:24am

Yes, I also had I2C enabled when trying to flash, but it’s a bit worrying to hear there’s a driver issue with the I/O expander. Hopefully it’s not that hard to fix, because we really need the co-processor up and running for some UPS control for a custom hat we have designed.

But thanks a lot for looking into this!

curcuz · September 26, 2019, 10:30am

@mad.dovejust to clarify: the raspbian image we build lacks this driver, while balenaOS is of-course all set. So the issue is about adding the driver, not the driver itself

mad.dove · September 26, 2019, 11:15am

Ahh ok, perfect. I’l cross my fingers and hope it won’t take to long to add then.

But does that actually also mean the driver can be manually installed from somewhere? Or do it need to go through the “balena mill” to work with the balenaFin?

afitzek · September 26, 2019, 11:26am

Hi,
Yes the required driver is this one https://github.com/torvalds/linux/blob/master/drivers/gpio/gpio-pca953x.c. You can either compile it as a kernel module or compile a full new kernel with this driver build-in.

mad.dove · September 26, 2019, 12:59pm

Hi afitzek,
Alright, thanks! I have never tried compiling a kernel module or a full new kernel before, but I’ll give it a shot.

afitzek · September 26, 2019, 1:10pm

Cool. Let us know how it goes.

mad.dove · September 27, 2019, 2:21pm

I have now managed to compile and install gpio-pca953x.c as a kernel module. I therefore included the “sysfsgpio_srst_num 510” line again in balena-fin-v1.1.cfg and ran flash.sh (with GPIO 41 set to 1).

The flashing succeeded with the exact same output as in my initial post to this thread. So that must mean GPIO 510 could now be found (since no errors were thrown). However, I’m still getting no response from the co-processor, when sending a version request over serial1/ttyS0 (with GPIO 41 is set to 0).

gpio-pca953x.c was the only driver missing for the flash to succeed right?

curcuz · September 27, 2019, 5:35pm

Hi @mad.dove I confirm that is the only driver you were missing. Did you perform a reboot after flashing? it is currently required ( more info here https://github.com/balena-io-playground/balena-fin-firmata-flash/issues/8 )

mad.dove · September 30, 2019, 3:13pm

Yes, I actually did reboot after flashing, but the problem turned out to lie elsewhere. I had only tried communicating with it over baud rate 9800 and 115200, but the firmware is set up to use 57600 (which I found out later by examining the firmware code). Once I switched to that, it started replying to my messages!

Now I just have another issue of it only replying to the first couple of my messages, then I have to reboot to get it replying again. But that might be something with my own code, so I’m currently looking into that.

Thanks a lot for the help!

curcuz · October 2, 2019, 11:52am

@mad.dove check if your raspbian is set to expose tty over that UART in /boot/cmdline.txt - it could be that you have shell garbage polluting your communication

mad.dove · October 2, 2019, 12:15pm

So I’m connecting to /dev/serial1 or /dev/ttyS0 and this is what my cmdline.txt looks like:

dwc_otg.lpm_enable=0 console=tty1 root=PARTUUID=8b46a562-02 rootfstype=ext4 elevator=deadline fsck.repair=yes rootwait quiet splash plymouth.ignore-serial-consoles

So I guess it could be:

console=tty1

but since it’s not console=ttyS0, I should be fine right?

curcuz · October 2, 2019, 12:46pm

@mad.dove yeah your config looks ok to me