hi there, the tools for flashing the co-processor rely on reading the hw revision from an EEPROM onboard balenaFin. Can you please run the following instructions to see what value is stored there?
within the device (any container shell):
curl -Ls https://github.com/balena-io/balena-fin-sdk/releases/download/v0.2.0/balena-fin-cli-v0.2.0.tar.gz | tar -xvz -C /usr/bin/
I did it from scratch. Using the production image balenaOS 2.72.0+rev1, as well as the developer one. And also try the oldest one available (2.36 rev2). All with same behaviour: /dev/ttyUSB0 not found.
thanks for checking - it seems the device does not have a value that is supposed to be stored in the EEPROM. Do you have the device at hand or is it remote? I would like to do a last test if possible (manually addind the value to the EEPROM and running the flashing container again)
If the device is at hand, can you please scan its QRcode (top side of the PCB) and flash that string onto the EEPROM via /usr/bin/fin eeprom --set <STRING> then read it back via /usr/bin/fin eeprom and then read revision via /usr/bin/fin revision
That value does not seem to be a valid balenaFin serial - are you sure you are scanning the squared black ink on white background QRcode sticker situated on the top of the PCB?
Almost there. It did try to update the firmware. All went few more steps until before reboot:
05.04.21 20:16:17 (+0100) flash stdout: releasing lockfile…
05.04.21 20:16:17 (+0100)
05.04.21 20:16:17 (+0100) flash stdout: closing the openocd process…
05.04.21 20:16:17 (+0100)
05.04.21 20:16:17 (+0100) rebooting via supervisor…
05.04.21 20:16:17 (+0100) setting fin-status tag to flashing…
05.04.21 20:16:17 (+0100) supervisor idle.
05.04.21 20:16:27 (+0100) failed to return firmware version, likely failed flashing.
And after reboot…the error:
05.04.21 20:17:41 (+0100) balenaFin revision 11
05.04.21 20:17:41 (+0100) server listening on port 1337
05.04.21 20:17:41 (+0100) setting fin-version tag to v1.1.1…
05.04.21 20:17:41 (+0100) 2021-04-05T19:17:41.451Z - info: [request-promise-retry] Encountered error Error: connect ECONNREFUSED 127.0.0.1:48484 for GET request to http://127.0.0.1:48484/v1/device?apikey=13338d31f99396bda56ed7c2417a2bfc, retry count 2
05.04.21 20:17:43 (+0100) 2021-04-05T19:17:43.480Z - info: [request-promise-retry] Encountered error Error: connect ECONNREFUSED 127.0.0.1:48484 for GET request to http://127.0.0.1:48484/v1/device?apikey=13338d31f99396bda56ed7c2417a2bfc, retry count 1
05.04.21 20:17:43 (+0100) ReferenceError: error is not defined
05.04.21 20:17:43 (+0100) at /usr/src/app/utils/supervisor.js:48:61
05.04.21 20:17:43 (+0100) at tryCatcher (/usr/src/app/node_modules/bluebird/js/release/util.js:16:23)
05.04.21 20:17:43 (+0100) at /usr/src/app/node_modules/bluebird/js/release/catch_filter.js:17:41
05.04.21 20:17:43 (+0100) at tryCatcher (/usr/src/app/node_modules/bluebird/js/release/util.js:16:23)
05.04.21 20:17:43 (+0100) at Promise._settlePromiseFromHandler (/usr/src/app/node_modules/bluebird/js/release/promise.js:547:31)
05.04.21 20:17:43 (+0100) at Promise._settlePromise (/usr/src/app/node_modules/bluebird/js/release/promise.js:604:18)
05.04.21 20:17:43 (+0100) at Promise._settlePromise0 (/usr/src/app/node_modules/bluebird/js/release/promise.js:649:10)
05.04.21 20:17:43 (+0100) at Promise._settlePromises (/usr/src/app/node_modules/bluebird/js/release/promise.js:725:18)
05.04.21 20:17:43 (+0100) at _drainQueueStep (/usr/src/app/node_modules/bluebird/js/release/async.js:93:12)
05.04.21 20:17:43 (+0100) at _drainQueue (/usr/src/app/node_modules/bluebird/js/release/async.js:86:9)
05.04.21 20:17:43 (+0100) at Async._drainQueues (/usr/src/app/node_modules/bluebird/js/release/async.js:102:5)
05.04.21 20:17:43 (+0100) at Immediate.Async.drainQueues [as _onImmediate] (/usr/src/app/node_modules/bluebird/js/release/async.js:15:14)
05.04.21 20:17:43 (+0100) at processImmediate (internal/timers.js:461:21)
Anycase: I try what I was looking for ( curl -X POST localhost:1337/sleep/10/60 ) and it did what was expected for the first time in 5 days! . At least I’m happy with the power-off thing. I still do recommend a video/documentation about the firmware and how customers can check the version. I saw the code in firmware.js was checking the balena firmware version…but wouldn’t guess how to set the firmware! Thanks!
Still having issues how to turn it on after sleep using a power button switch. Can you help me with that? Is there any other thread where this is described? I can only trigger it on if using a push button between PC9 and 5V from gpio. But it also resets if push while powered-on.
Sorry @curcuz , but the issue is still there. I format the eMMC with the production image…add the firmware flash from above…and again the error shows:
07.04.21 16:41:36 (+0100) Started service ‘co-processor sha256:b1e34aff0d54591ac2a904efc0a975f0fa9355eceb8261fc39d329b67866a7fd’
07.04.21 16:41:39 (+0100) balenaFin revision 11
07.04.21 16:41:39 (+0100) server listening on port 1337
07.04.21 16:41:39 (+0100) (node:16) UnhandledPromiseRejectionWarning: Error: Error: No such file or directory, cannot open /dev/ttyS0
07.04.21 16:41:39 (+0100) (node:16) UnhandledPromiseRejectionWarning: Unhandled promise rejection. This error originated either by throwing inside of an async function without a catch block, or by rejecting a promise which was not handled with .catch(). To terminate the node process on unhandled promise rejection, use the CLI flag --unhandled-rejections=strict (see Command-line options | Node.js v15.14.0 Documentation). (rejection id: 1)
07.04.21 16:41:39 (+0100) (node:16) [DEP0018] DeprecationWarning: Unhandled promise rejections are deprecated. In the future, promise rejections that are not handled will terminate the Node.js process with a non-zero exit code.
UPDATE: By some reason, the ttyS0 is not there…neither ttyUSB0
Hey. We have identified an incident in the manufacturing process related to this issue. It is going to be discussed internally (likely today), and further instructions will be provided. Stay tuned!
To elaborate a bit on my colleague’s message, all balenaFins v1.1.x get the serial number (the one on the QR code) programmed on the EEPROM after manufacturing. This is how we identify them during the coprocessor flashing process. We’ve identified a problem in the programming process that caused a batch of balenaFins not to have the EEPROM correctly programmed.
We’ve now fixed this and are working on a process to allow users to read the QR code and flash the EEPROM. This is what my colleague Carlo requested you to test.
In your last message, you mentioned that the device is failing to program the coprocessor again after an eMMC reflash. Is this the same device where you programmed the EEPROM? If so, we might have a different issue, as the EEPROM should not be affected at all by flashing/formating the eMMC.
. At least I’m happy with the power-off thing. I still do recommend a video/documentation about the firmware and how customers can check the version. I saw the code in firmware.js was checking the balena firmware version…but wouldn’t guess how to set the firmware! Thanks!