How to detect version of application and not of the bootloader?

[RobertDaleSmith]

I am building a GUI to automate running the command line tool. I would like for my GUI application to be able to detect the version of the application installed on the device. I see the command line tool reports the version of the bootloader but would it be possible to update this version number set in the bootloader device information when flashing a new application firmware update through micronucleus?

Basically looking for a way I can programmatically detect versions of the application so my GUI can report whether an update is needed or not.

I have brainstormed that maybe I could download the flashed firmware and do an MD5 check on the file in order to make an educated guess of which previous version of my application is installed when compared to a hash table. But would be nice if when updating through micronucleus command line it just goes ahead and bumps the version defined in the bootloader device info.

Any help or direction on this topic is greatly appreciated. 🙏

[cpldcpu]

By design micronucleus is set up in a way where it is completely agnostic to the content that is uploaded. Therefore, no mechanism exists to read the content of the user space. In a normal setting, the bootloader also would only be invoked when a new firmware is uploaded, so the application itself should respond to version request while it is active.

Of course, you can extend Micronucleus however you like for your own needs. For example, you could store version information in your application in a certain place and extend micronucleus to output that information. But, as said before, a cleaner architecture would for the application software to send out a version reply.

[RobertDaleSmith]

For my device I am only using USB for firmware updates. So my application software does not report anything through USB (currently). I think for my case, extending Micronucleus will do. I added version bytes to beginning of my application.

version:  .db 0x01, 0x05

and I see it in the application header at the beginning:

:020000020000FC
:020000000105F8

Not as familiar with C, any tips on how I could read those version bytes from flash memory and into usbDescriptorDevice[]?

[cpldcpu]

It's actually not that simple. What you could do is to add a new function in the main command loop, like for the configuration reply:

https://github.com/micronucleus/micronucleus/blob/master/firmware/main.c#L250

(You could also use the configuration reply to transfer your version information, it currently does not use the device id).

You would also have to adjust the commandline tool to output the new information.

[RobertDaleSmith]

You were right, this has not been simple. Still trying to figure out how to get the application version passed through the configuration reply. Once I do figure out how to pass that value, not sure how or where to put the value you in the usbDescriptorDevice.

Also micronucleus command line or avrdude can not read the application but rather only program it?

[RobertDaleSmith]

@cpldcpu I successfully added some dummy version data onto the configurationReply and have it render in the command line tool.

PROGMEM const uint8_t configurationReply[8] = {
  (((uint16_t)PROGMEM_SIZE) >> 8) & 0xff,
  ((uint16_t)PROGMEM_SIZE) & 0xff,
  SPM_PAGESIZE,
  MICRONUCLEUS_WRITE_SLEEP,
  SIGNATURE_1,
  SIGNATURE_2,
  1, // app major ver
  5  // app minor ver
};

But I am having a hard time figuring out how to actually set these values on the fly in usbFunctionSetup(). Any tips on how I can update these?

[cpldcpu]

You could try removing the "PROGMEM const" keyword. Then the array will be mapped to SRAM. I hope the functions to send from sram are still in micronucleus, though :)

[RobertDaleSmith]

Yea that was one of the first things I tried but when I do so micronucleus behaves as if that configurationReply is not defined. I will keep tinkering and see what I can figure out.

[cpldcpu]

A lot of code has been removed from V-USB to reduce code size. It's possible that the function to send from SRAM are not there anymore.

[RobertDaleSmith]

Dang yea I have been banging my head against this one. I reverted to before these changes: 0b04751

but still same issue, so must have been another commit. @ArminJo I saw you made this commit to clean up usbdrv. Do you think any of these changes could be related to the function to send from SRAM?

[ArminJo]

I think, with your extensions you get a macronucleus bootloader.

Better think of printing a line at startup of your program like
Serial.println(F("START " __FILE__ " from " __DATE__ "\r\nUsing library version " VERSION_OF_LIBRARY));
Or just a binary with
writeBinary(VERSION_OF_LIBRARY); // 1 Byte binary output
using the https://github.com/ArminJo/ATtinySerialOut library.
Code size is only 76 Bytes@38400 baud or 196 Bytes@115200 baud (including first call).

[cpldcpu]

@RobertDaleSmith

You have to add the original implementation of '''usbDeviceRead''' to usbdrv.c. Copying from RAM has indeed been removed in micronucleus.

see here:

https://github.com/obdev/v-usb/blob/7a28fdc685952412dad2b8842429127bc1cf9fa7/usbdrv/usbdrv.c#L497

@ArminJo

Using the existing descriptor should be quite a small addition.

[ArminJo]

@cpldcpu
The small addition to read 2 extra bytes from RAM costs 66 bytes program space :-(
I included it anyway with an compiler switch STORE_CONFIGURATION_REPLY_IN_RAM.
So it might be more sensible to overwrite the FLASH location by the user program ( if required).
Extending the FLASH reply by 2 bytes costs only 2 bytes 😀

@RobertDaleSmith

and have it render in the command line tool.

How did you manage this?

[RobertDaleSmith]

@ArminJo

and have it render in the command line tool.

How did you manage this?

I read two bytes for program version here: https://github.com/micronucleus/micronucleus/compare/master...RobertDaleSmith:snes23do-app-version-lite?expand=1#diff-4c3b3752bbaffdc43c97424bc76d63e305bdca404f04c4aa3f2a92333f444b48R252.

Then I grab it on the other end in the command line tool here:
https://github.com/micronucleus/micronucleus/compare/master...RobertDaleSmith:snes23do-app-version-lite?expand=1#diff-e9704eada222731b553468f6b0a747011660e4056b25f66ec220a33b5a16828fR125.