Unable to Flash the Co-Processor

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. :slight_smile:

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

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.

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?

Is it possible to proof that?

You can find it in the dashboard:

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

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?

Good morning @bucknalla , any idea why I would be using an older version when I just pushed a new build?

Well this looks interesting:

:thinking:

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? :slightly_smiling_face:

Thanks!

1 Like

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

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!

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.