Workbench doesn't build correct firmware and/or false flash

Hi folks,

Not sure if a new Workbench bug, but chasing subject issue and finally found a work-around but don’t understand what’s going on…

To preface,
Already tried these as described in prior thread here (and as shown in screenshoot below):

  • ‘clean app and OS (local)’
  • ‘reload window’
  • 'build app and OS (local)

image

Even tried to start a new build task (new VS Code makefile?) as shown here:
image

Notes,

  • Able to ‘particle flash --usb tinker’ from CLI (which works), then back to local compile/flash custom firmware but NOGO (again, appears to work but ‘wrong’ firmware)
  • Fun fact, opening ‘particle serial monitor’ in CLI in cmd window separate from Workbench right after a flash actually crashes the computer (blue screen of death), not sure if a weird interaction?
  • Side question, why is your app called ‘firmware’ and Particle firmware called ‘OS’?

FINALLY, found that ‘cloud compile’ and either a ‘local flash’ (type in the name of the .bin) or ‘cloud flash’ works. But why?

Both are firmware as they reside in firm (non-volatile) flash memory.
The OS firmware provides the basis (operating system) for the application firmware.
Just as WIndows/Linux/MacOS are software just the same as any application running ontop of the respective OSs.

Can you run particle binary inspect on the binary you get from your local build?

Copy that, and much appreciate the quick reply.

Here you go on ‘particle binary inspect …’:

Something else may be funny too, because the Particle vars, funcs are NOT available in console, despite everything compiling great (and Intellisense happy too). Perhaps this is just a symptom right now…

And quite literally the build ‘local app + OS’ (in VS Code) makes it a ‘monolithic’ build right?

Nope, it will build multiple binaries.
IIRC only when building for debugging it will be monolithic.

So it’s running OS 3.0.0, recommend a change?

If so, isn’t ideal method to set the OS target version in Workbench, and then local and/or cloud flash to do it right?

Another note, the device is part of a Particle Product and flagged as a development device, wonder if it will take a cloud flash without needing to erase the Product firmware (ex, with ‘particle flash --usb tinker’)?

At this point think I suspect it’s a file location issue, like files on an attached hard drive, even though hard wired and NOT in the cloud.

Means rebuilding everything ‘locally’ (on OS drive of the PC) appears to simplify build, and avoids funny stuff like ‘warning timestamp out of range’.

Although still not seeing all functionality, so standby for final update.

Speaking of that, is there a handy ‘logger’ app that shows the device ‘booting up’ incl. status of peripherals, maybe LTE too?

Also I’m reading docs and do see the SerialLogHandler which looks great…
Now, does it make sense to use THIS (like global logging) AND the generic Serial.print() (specific events)?

You should not mix the two. You should only use Log.info() and its relatives and the SerialLogHandler and not use Serial.println() and its relatives.

Along other things, the Log.* calls are thread safe, work with multiple output options (Serial1 UART, UDP syslog, SD card, etc.) and that’s what’s used by the system, so you can also get the system logging messages (or disable them, if you prefer).

1 Like

Thanks again Rickkas! You, ScruffR, and the team are legends, been on here for years. Specifically I recall your serial tutorial and cellular debugging app too. :smiley:

And great docs, they’ve really come a long ways! I got a couple books too, I like Packt and Manning. But your docs give them a run for the money.

A follow-up note, as suggested in docs, might have to ‘expedite’ the Particle funcs/vars definitions before setup() {} finishes so they actually register for the cloud to recognize… though how much to expedite I don’t know, like where in setup() do they belong, very beginning or somewhere in middle? Too bad you can’t just call Particle.connect() after the defs (I tried and think it’s already called in background before I call it).

When Particle.connect() is called depends on your SYSTEM_MODE() and whether you use SYSTEM_THREAD(ENABLED) or not.

You can prepare Particle.function(), Particle.variable() and Particle.subscribe() to be registered, before and up to shortly after the cloud connection is established.
The earlier the better IMHO.

The earliest you can do it is in a STARTUP() macro.

2 Likes

I’ll mark this as the fix.
Many thanks for everyone’s input.

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.