Firmware flash via J-Link

Custom Widgets
1

Hello all,

I’m trying to design a new widget to upload firmware to the device in production via J-Link.
Searching the internet I cannot find any widgets offering this functionality, has anyone already done a similar integration?

Thanks & Regards,
Emanuele.

2

Hi Emanuele - Welcome to the Tulip Community :tada: We are glad you are here!

I have a couple questions around what you are trying to do so that the Community can better assist you:

  • What type of firmware are you trying to upload?
  • When you say “device” what specifically do you mean?

Thanks!

Beth

3

Hi Beth,

We produce IoT devices, one step of production is the flash of the firmware inside the device that the operator is assembling. In this case, by device I mean the IoT device that the operator is assembling.
To flash the firmware in the IoT device, it is necessary to use a programmer (the J-Link device in our case) that is connected via USB to the production PC. The programmer (J-Link) has management software via CLI, in particular there is a cli command that given a file (firmware to load) and some parameters allows the firmware to be flashed.

Initially, the idea was to create a custom widget whose JS code uses CLI terminal commands to communicate with the J-Link programmer. In this case, the file (firmware) to be flashed to the IoT device would be passed to the widget via a file-type prop.

Is this feasible?

Thanks for your time.
Emanuele

4

Hey Emanuele!

Great question! Happy to help, it’s an interesting case.

First thing to note here is that Custom Widgets are pretty heavily sandboxed in Player; not to say that it’s impossible, but I have had trouble in the past with CWs attempting to contact the hardware it’s running on; for example here running console commands from within Player. Most likely, the only way that I have seen a custom widget communicating with other programs on a computer is via API calls over localhost.
That being said, if you are able to communicate over a localhost port to J-Link, that may be a way to accomplish your needs.

Aside of all of this, worth asking - are you using a flashing jig, or some middle-device like a Pi to accomplish the flashing itself? I have seen users have success before in a structure like this:

  1. IoT device (perhaps many) plug into flashing device (e.g. a Pi)
  2. Flashing device has all necessary image files
  3. Flashing device is plugged into user computer as simple serial device
  4. User computer can trigger new flash commands via Serial
  5. Flashing device accomplishes image burn, reports back with some data

this way, you’re avoiding the actual command-line configuration in Tulip and simply sending a “go” command.

Regardless, I’m curious if anyone else has experience with similar setups! Let me know if this helps!

5

Ah! I was also just reminded that you can likely accomplish this via Node-RED: in this case, using a Tulip Edge Device to essentially substitute for points 2 through 4 here, simplifying things a bit. It’s not a major improvement as you still would need to write your flashing script, manage configuration etc but Node-RED may make it a bit easier to configure.

6

Hi Kyle,

Thank you for your reply.
We wanted to save the firmware file in a Tulip table, as the product code also defines which firmware is to be flashed.
Maybe with Node-RED we can pass the file (firmware) and then run the terminal command with the correct file directly from Node-RED.
So the flow would be: File in tulip table → Node-RED → Flash command from Node-RED

7

@ezamp right, that seems like a valid method. Once within node-red, you can do whatever you need - including running Python or Javascript. (in truth, perhaps it may be easier to simply run Python directly on e.g. a Raspberry Pi or ODroid rather than a Tulip edge device, from within node-RED - but either would work).
You could also (probably) save the file on your Edge Device for easier application, as there are file read/write nodes (but I haven’t used them myself). After this, simply send the product code to the Device rather than the full file itself.