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:
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?
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?
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:
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
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.
@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
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?
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?
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.
@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
