crbn60
December 8, 2021, 1:03am
1
I see another similar thread, but I’m not sure if this is the same issue. I am unable to flash the co-processor, the output is as follows:
Copying bootloader.s37
Firmata version set to v2.0.1
Downloading v2.0.1 firmata firmware.
https://github.com/balena-io/balena-fin-coprocessor-firmata/releases/download/v2.0.1/firmata.hex
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 171 100 171 0 0 585 0 --:--:-- --:--:-- --:--:-- 583
100 650 100 650 0 0 1473 0 --:--:-- --:--:-- --:--:-- 1473
100 124k 100 124k 0 0 154k 0 --:--:-- --:--:-- --:--:-- 154k
setting fin-status tag to awake...
setting wake-eta tag to N/A...
balenaFin revision 09
server listening on port 1337
setting fin-version tag to v1.0.0...
[Error: Error: No such file or directory, cannot open /dev/ttyUSB0]
supervisor {
supervisor api_port: 48484,
supervisor ip_address: '10.0.19.5',
supervisor os_version: 'balenaOS 2.83.21+rev1',
supervisor mac_address: 'B8:27:EB:A2:02:70 48:A4:93:04:2F:9A 6A:FA:23:D1:66:95',
supervisor supervisor_version: '12.11.16',
supervisor update_pending: false,
supervisor update_failed: false,
supervisor update_downloaded: false,
supervisor commit: '85010cd37033649c7dbb3c6ba5ebcc4c',
supervisor status: 'Idle',
supervisor download_progress: null
supervisor } +0ms
supervisor idle.
ConfigVars are set.
Need to reboot supervisor? false
Target firmware version: [StandardFirmata/v2.0.1]
firmata Calling queryfirmware +0ms
Cannot query firmware
Start automatic flashing: installing firmata v2.0.1
flash stdout: acquiring lockfile...
flash stdout: opening screen terminal for flashing firmata-v2.0.1.hex to balenaFin v09
flash stderr: telnet: Unable to connect to remote host: Connection refused
Error: Flashing failed with message: telnet: Unable to connect to remote host: Connection refused
at Socket.<anonymous> (/usr/src/app/flasher.js:39:22)
at Socket.emit (events.js:314:20)
at addChunk (_stream_readable.js:297:12)
at readableAddChunk (_stream_readable.js:272:9)
at Socket.Readable.push (_stream_readable.js:213:10)
at Pipe.onStreamRead (internal/stream_base_commons.js:188:23)
flash stdout: Trying ::1...
Trying 127.0.0.1...
flash failed! device will not reboot.
Any way to kick it around this?
For some background: this is a balenaFin that was in use for an old project that I recently decided to repurpose.
Hey @crbn60
Am I right that you’re using the fin block here? I think that looks like the logging from that block.
If so, I know that the block has had a lot of work lately - so it’s worth checking the latest readme:
fin/01-getting-started.md at master · balenablocks/fin (github.com)
Do you have all of the requirements for the block in your docker-compose file?
Phil
1 Like
crbn60
December 8, 2021, 1:06pm
3
Oups, I should have included the details, eh? Sorry about that.
Here is the relevant docker-compose.yaml
excerpt:
fin:
restart: always
image: balenablocks/fin:latest
network_mode: host
privileged: true
volumes:
- "fin:/data/firmware"
labels:
io.balena.features.supervisor-api: "1"
io.balena.features.balena-api: "1"
environment:
- "DEBUG=firmata,flasher,downloader,supervisor,eeprom,main"
- "AUTOFLASH=1"
- "AUTOCONFIG=1"
expose:
- "1337"
From the last time I was working with GPIO, isn’t there some variables that need to be set for DT overlays or some such? Sorry, I didn’t take notes…
Thanks for your help,
A.
@crbn60 the block should be setting the dtoverlay to balena-fin
We might need to put the bat signal up and summon @bucknalla for some expert help.
crbn60
December 8, 2021, 1:10pm
6
I notice that the documentation file has a simpler docker-compose.yaml entry than the version deployed if you use the magic blue button. Notably, it adds:
cap_add:
- NET_ADMIN
- SYS_ADMIN
- SYS_RAWIO
labels:
io.balena.features.sysfs: '1'
io.balena.features.kernel-modules: '1'
Are those required?
crbn60
December 8, 2021, 1:19pm
7
Is it possible to proof that?
You can find it in the dashboard:
crbn60
December 8, 2021, 1:32pm
9
I see only custom variables at the bottom:
Nothing is activated above. Could that be an issue?
Hi @crbn60 ,
It looks like from your logs that you are using an old version of the fin block. Could you please try pulling a new image or starting a new build against your balenaFin? Could you also please confirm for me which version of the balenaFin you are using (e.g. v1.0 or v1.1)?
Thanks!
1 Like
crbn60
December 8, 2021, 6:03pm
11
The logs are from a new build, actually. Is the newest block not tagged with latest?
I purchased this balenaFin some time ago, not sure which version it is. Is there a simple way to confirm?
crbn60
December 9, 2021, 12:51pm
12
Good morning @bucknalla , any idea why I would be using an older version when I just pushed a new build?
crbn60
December 10, 2021, 2:02am
13
Well this looks interesting:
balenablocks:master
← balenablocks:publish-dockerhub
opened 11:22PM - 09 Dec 21 UTC
Change-type: minor
Signed-off-by: Alex Bucknall <alex.bucknall@gmail.com>
1 Like
Hi @crbn60
Yep, I noticed our fin block repo wasn’t publishing to docker hub. Could you try pulling for a new image again please?
Thanks!
1 Like
crbn60
December 10, 2021, 12:30pm
15
I pushed a new build and that puts it into a reboot loop:
Supervisor starting
<fin> main fin-block version: 3.6.0 +0ms
<fin> eeprom readSerial stdout: ��������������������� +0ms
<fin> eeprom readSerial stderr: +1ms
<fin> eeprom FTDI chip check stdout: Bus 001 Device 003: ID 0424:ec00 Standard Microsystems Corp. SMSC9512/9514 Fast Ethernet Adapter
<fin> eeprom Bus 001 Device 002: ID 0424:9514 Standard Microsystems Corp. SMC9514 Hub
<fin> eeprom Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
<fin> eeprom +763ms
<fin> eeprom FTDI chip check stderr: +1ms
<fin> eeprom false +1ms
<fin> eeprom EEPROM is not flashed, assuming hw revision 11 based on the absence of the FTDI chip FT2232C (present only on hw rev 09) +6ms
<fin> eeprom {
<fin> eeprom schema: NaN,
<fin> eeprom hardwareRevision: 11,
<fin> eeprom batchSerial: NaN,
<fin> eeprom week: NaN,
<fin> eeprom year: NaN,
<fin> eeprom pcbaLot: '���������',
<fin> eeprom RAW: '���������������������'
<fin> eeprom } +0ms
<fin> firmata hardware revision is 11 - connecting firmata over /dev/ttyS0 +0ms
<fin> main autoflash is set to 1 +989ms
<fin> firmata Calling queryfirmware +22ms
<fin> main autoconfig is set to 1 +4ms
<fin> firmata firmware metadata cannot be obtained +10s
<fin> main running firmata implementation version: +10s
<fin> downloader latest firmware version tag found is 2.0.1 +0ms
<fin> main target firmware 2.0.1 is not already running, downloading it for flashing... +663ms
<fin> downloader downloading firmware file https://github.com/balena-io-hardware/balena-fin-coprocessor-firmata/releases/download/v2.0.1/firmata.hex as file /data/firmware/firmata-v2.0.1.hex +15ms
<fin> downloader /data/firmware/firmata-v2.0.1.hex exists already, skipping download... +1ms
<fin> main target firmware downloaded, starting flash... +2ms
<fin> eeprom readSerial stdout: ��������������������� +11s
<fin> eeprom readSerial stderr: +0ms
<fin> eeprom FTDI chip check stdout: Bus 001 Device 003: ID 0424:ec00 Standard Microsystems Corp. SMSC9512/9514 Fast Ethernet Adapter
<fin> eeprom Bus 001 Device 002: ID 0424:9514 Standard Microsystems Corp. SMC9514 Hub
<fin> eeprom Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
<fin> eeprom +81ms
<fin> eeprom FTDI chip check stderr: +1ms
<fin> eeprom false +3ms
<fin> eeprom EEPROM is not flashed, assuming hw revision 11 based on the absence of the FTDI chip FT2232C (present only on hw rev 09) +1ms
<fin> eeprom {
<fin> eeprom schema: NaN,
<fin> eeprom hardwareRevision: 11,
<fin> eeprom batchSerial: NaN,
<fin> eeprom week: NaN,
<fin> eeprom year: NaN,
<fin> eeprom pcbaLot: '���������',
<fin> eeprom RAW: '���������������������'
<fin> eeprom } +2ms
<fin> main balenaFin HW revision is 11 +148ms
<fin> supervisor setting lockfile... +0ms
<fin> flasher attempting to flash firmware: /data/firmware/firmata-v2.0.1.hex with bootloader: /data/firmware/bootloader.s37 +0ms
<fin> flasher flashing state: 0 +4ms
<fin> flasher spawning openocd process with debug level set to 2 and board config -d2,-f,board/balena-fin/balena-fin-v1-1.cfg +1s
<fin> flasher spawning telnet client process... +10s
<fin> flasher telnet stdout: Trying ::1...
<fin> flasher Trying 127.0.0.1...
<fin> flasher Connected to localhost.
<fin> flasher Escape character is '^]'.
<fin> flasher Open On-Chip Debugger
<fin> flasher
> +61ms
<fin> flasher telnet stdout: rese +988ms
<fin> flasher telnet stdout: t halt
<fin> flasher +2ms
<fin> flasher telnet stdout: Could not find MEM-AP to control the core
<fin> flasher Target not examined, reset NOT asserted!
<fin> flasher
<fin> flasher
> program /data/firmware/bootloader.s37
<fin> flasher +1s
<fin> flasher telnet stdout: Could not find MEM-AP to control the core
<fin> flasher Target not examined, reset NOT asserted! +1s
<fin> flasher telnet stdout:
<fin> flasher embedded:startup.tcl:596: Error: ** Unable to reset target ** +2ms
<fin> flasher telnet stdout:
<fin> flasher in procedure 'program'
<fin> flasher in procedure 'program_error' called at file "embedded:startup.tcl", line 633
<fin> flasher at file "embedded:startup.tcl", line 596
<fin> flasher
> +1ms
<fin> flasher telnet stdout: reset halt
<fin> flasher +8s
<fin> flasher telnet stdout: Could not find MEM-AP to control the core
<fin> flasher +1s
<fin> flasher telnet stdout: Target not examined, reset NOT asserted!
<fin> flasher
<fin> flasher
> pr +1ms
<fin> flasher telnet stdout: ogram /data/firmware/firmata-v2.0.1.hex
<fin> flasher +4ms
<fin> flasher telnet stdout: Could not find MEM-AP to control the core
<fin> flasher Target not examined, reset NOT asserted!
<fin> flasher +1s
<fin> flasher telnet stdout: embedded:startup.tcl:596: Error: ** Unable to reset target **
<fin> flasher in procedure 'program'
<fin> flasher in procedure 'program_error' called at file "embedded:startup.tcl", line 633
<fin> flasher at file "embedded:startup.tcl", line 596
<fin> flasher +2ms
<fin> flasher telnet stdout:
> +4ms
<fin> flasher telnet stdout: res +28s
<fin> flasher telnet stdout: et run
<fin> flasher +1ms
<fin> flasher telnet stdout: Could not find MEM-AP to control the core
<fin> flasher +1s
<fin> flasher telnet stdout: Target not examined, reset NOT asserted!
<fin> flasher
<fin> flasher
> +1ms
<fin> flasher telnet stdout: shu +4s
<fin> flasher telnet stdout: tdown
<fin> flasher +1ms
<fin> flasher telnet stdout: shutdown command invoked
<fin> flasher +3ms
<fin> flasher telnet stderr: Connection closed by foreign host.
<fin> flasher +8ms
<fin> flasher telnet child process exited with code 1 +3ms
<fin> flasher openocd child process exited with code 0 +13ms
Killing service 'fin sha256:b05b511ad538a25fa855f56673cea1fb446aa2db52221354432e7c1c9447008c'
<fin> supervisor releasing lockfile... +1m
<fin> main firmware 2.0.1 flashed. needsReboot is true +1m
<fin> main rebooting +0ms
Looks like it is still trying to flash 2.0.1
though. And I have nothing flash in the eprom, apparently. Anything else I can try?
Thanks @crbn60 ,
Ok it seems like you have a balenaFin v1.1.x by the absence of the FTDI IC.
Let me take a look at this locally; it seems there’s something going wrong with the OpenOCD process trying to flash the coprocessor.
1 Like
crbn60
December 16, 2021, 2:08am
17
Any luck reproducing this @bucknalla ?
Hi @crbn60 ,
I haven’t been able to reproduce this error on any of my devices. It seems as though something is stopping OpenOCD from taking control of the coprocessor’s SWDIO interface. I’m checking this with another colleague to see if they have come across this issue before.
Thanks for your patience!
crbn60
December 20, 2021, 2:08pm
19
That’s for the update. I’m interested in helping debug this, so let me know if I can do anything to provide more data.
Thanks for your help,
A…
Hi @crbn60 would you be able to provide us with a log of your dmesg please? If you could capture the output from dmesg -w
it would be useful to see if the kernel has anything to say during the flashing process.