Struct lpc55::bootloader::Bootloader
source · [−]Fields
protocol: Protocol
vid: u16
pid: u16
uuid: u128
Implementations
sourceimpl Bootloader
impl Bootloader
sourcepub fn try_new(vid: Option<u16>, pid: Option<u16>) -> Result<Self>
pub fn try_new(vid: Option<u16>, pid: Option<u16>) -> Result<Self>
Select a unique ROM bootloader with the given VID and PID.
sourcepub fn try_find(
vid: Option<u16>,
pid: Option<u16>,
uuid: Option<Uuid>
) -> Result<Self>
pub fn try_find(
vid: Option<u16>,
pid: Option<u16>,
uuid: Option<Uuid>
) -> Result<Self>
Attempt to find a unique ROM bootloader with the given VID, PID and UUID.
sourcepub fn find(vid: Option<u16>, pid: Option<u16>, uuid: Option<Uuid>) -> Vec<Self>
pub fn find(vid: Option<u16>, pid: Option<u16>, uuid: Option<Uuid>) -> Vec<Self>
Finds all ROM bootloader with the given VID, PID and UUID.
pub fn info(&self)
pub fn reboot(&self)
pub fn enroll_puf(&self)
sourcepub fn read_memory(&self, address: usize, length: usize) -> Vec<u8>
pub fn read_memory(&self, address: usize, length: usize) -> Vec<u8>
The reason for this wrapper is that the device aborts early if more than 512 bytes are requested. Unclear why it does this…
This is a traffic trace (requesting all of PFR in one go), removing the “surplus junk”
–> 01002000 03000002 00DE0900 000E0000 00000000 00000000 00000000 00000000 00000000 <– 03000C00 A3010002 00000000 000E0000 <– 04003800 00000000 02000000 02000000 02000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 <– 04003800 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 <– 04003800 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 <– 04003800 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 <– 04003800 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 02000000 00000000 00000000 00000000 00000000 00000000 <– 04003800 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 <– 04003800 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 <– 04003800 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 <– 04003800 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 ECE6A668 2922E9CC F462A95F DF81E180 E1528642 7C520098 <– 04000000 <– 03000C00 A0000002 65000000 03000000
The error is 101 = 100 + 1 = (supposedly) a flash driver “alignment” error (?!)
The interesting thing is that at the point where the device aborts, there are 8 bytes remaining, which it otherwise produces in a final
<– 04000800 2C80BA51 B067AF3C <– 03000C00 A0000002 00000000 03000000
TODO: should we just enter our desired length anyway, and handle such situations? As in retry at the new index, with the reduced length? Instead of using a fixed 512B chunking?
TODO: Need to expect errors such as: Response status = 139 (0x8b) kStatus_FLASH_NmpaUpdateNotAllowed
This happens with read-memory $((0x0009_FC70)) 16
, which would be the UUID
TODO: Need to expect errors such as: Response status = 10200 (0x27d8) kStatusMemoryRangeInvalid
This happens with read-memory $((0x5000_0FFC)) 1
, which would be the DIEID (for chip rev)