pico_get_unique_board_id_string endianness is big-endian

[Poofjunior]

It looks like the RP2040 is little-endian, but the unique id retrieved from the Winbond flash as printed in pico_get_unique_board_id_string populates the USB descriptor field as big-endian.

From the source, it looks like flash_get_unique_id retrieves the data as little-endian (since the system is little-endian) with:

    flash_do_cmd(txbuf, rxbuf, FLASH_RUID_TOTAL_BYTES);
    for (int i = 0; i < FLASH_RUID_DATA_BYTES; i++)
        id_out[i] = rxbuf[i + 1 + FLASH_RUID_DUMMY_BYTES];  // Copy direction is consistently increasing.

If I dump the data with memcpy like so:

uint8_t uuid[8];  
memcpy((void*)(&uuid[]), (void*)&(unique_id.id), sizeof(unique_id.id));

and then print the resulting array, I get (as expected):

But reading the device descriptor field (populated by pico_get_unique_board_id_string), we get:

But we should get: 2B686B83C25C63E6 where 0xE6 is the least significant byte.

The mistake is in pico_get_unique_board_id_string. Here, bytes are populated least-significant to most-significant, but the string will be printed and read with the least significant byte starting at index 0, making the string read most-significant-to-leas-significant.

[kilograham]

You should not rely on this API being the same as the flash id (it isn't on RP2350 for example).

I'm closing this as not planned therefore. Note that you can call flash_get_unique_id yourself - is there a reason you have to use pico_get_unique_board_id()?