I found a copy here, but I'm not sure if it's the right one (and my guess is they weren't actually supposed to upload it to GitHub): https://github.com/bluewind-embedded-systems/aws-nxp-lpc54018-demo/blob/master/NXP/libs/libpower_hardabi.a

I also needed to make this small substitution:

   Compiling lpc55s6x-hal v0.0.1 (/home/jwilcox/repo/lpc55s6x-hal)
error[E0412]: cannot find type `PIO1_6` in module `pins`
  --> examples/rtfm_led.rs:16:30
   |
16 | type RedLed = hal::Pin<pins::PIO1_6, states::pin_state::Gpio<states::gpio_state::direction::Output>>;
   |                              ^^^^^^
help: a struct with a similar name exists
   |
16 | type RedLed = hal::Pin<pins::Pio1_6, states::pin_state::Gpio<states::gpio_state::direction::Output>>;
   |                              ^^^^^^
help: possible candidate is found in another module, you can import it into scope
   |
6  | use lpc55s6x_pac::iocon::PIO1_6;
   |

Once I did those two things (and flashed the JLink firmware onto my board) the rtfm_led example worked great!

rtic 0.6 is pretty close to a full release, so it would be good to start updating the examples for that.

It would be great to evaluate the bootloader + signed updates using LPC55's ROM.

A good overview is given in AN12283.

I image successful (green) and failed (red) signed updates would follow these paths.

And the application can have the ability to jump to the ISP/bootloader-rom to start the update process. The answer to this forum post makes it look pretty simple.

There are a few not-so-trivial things to configure.

• The public key chain loaded into the bootloader ROM.
• Other bits in CMPA + CFPA pages.

To access the latest "elftosb" and "elftosb-gui" tools, you need to download an MCUXpresso kit and make sure you have mcu-boot option enabled.

I have some not-easy-to-find documents giving good documentation + examples of configuring LPC55 with elftosb. Message me on Keybase (conor1) and I will send to you.

It would be great to be able to:

• Create an example Rust program that can boot to bootloader ROM after receiving some event (like a USB command).
• Create a demo that configures that configures the bootloader ROM.
• Update the ROM with a signed update.
• Update the ROM with an unsigned update (fail).
• Maybe try revocation of a certificate?

Open to feedback!

(cc @jolo1581).

I am still unsure if it is simply my inexperience with embedded software, or an actual issue but I have spent enough time debugging to be comfortable enough saying its something with the HAL (or NXP).

I have tried a different board and everything in this. It would be nice to get an error or some indication of failing, but it does so silently. The repo above uses the raw cortex_m methods, but the main branch contains a non-working example using rtic 0.6 (I have tried with 0.5, but didn't save the repo). Since this repo was built using UM11126 which NXP applies for s28 and 28, I cannot see where a PAC generated for s69 would be different. I did try and compile a local PAC and HAL using the 13.1.0 CMSIS for LPC55S28 which also lead nowhere (the NVIC register block should be the same anyways according to NXP).

The debugger is programmed with the latest JLink firmware available, though I am suspicious of it. I would like to try and debug with probe-rs, but that is not ready yet.

Otherwise, accidentally clears other interrupt statii.

https://github.com/nickray/lpc55s6x-hal/blob/ebbb8cf1d41c508ae983459560f3be63bc9adbdf/examples/rtfm_led.rs#L17 doesn't build.

cf. lpc-rs/lpc8xx-hal#159 (comment)

Puf::enabled only waits until the PUF is not busy, but it should also check whether the status is error or success.

If the PUF is already started (e. g. by the ROM), executing the START operation is no longer allowed. Instead, GET_KEY can be executed directly. This is currently not allowed by the Puf API.

I've started bringing up a new custom board based on the LPC5514 using this crate. So far, most things appear to be pretty well compatible, but I did run into an issue with the USB SRAM - on the 551x chips, the USB SRAM is mapped at 0x20010000 rather than at 0x40100000 as in their bigger-brother LPC55S69 cousins:

From what I can tell, this would be the first change in the crate for another chip family member. In other crates I've used like the stm32 hal packages, these differences are to be handled with feature flags. Would a similar strategy be the best way forward here? I suspect we could detect this particular difference easily at runtime as well. I can put together a PR if that would be helpful. :)

Hi,
I did an update by make rustup.
Now I get following warning

make run-example
cargo run --example led_utick
   Compiling lpc55-hal v0.0.3 (/home/jan/Projects/lpc55-hal)
warning: unnecessary parentheses around block return value
   --> src/drivers/touch.rs:310:13
    |
310 |             ((((sync_time - 3513)/1598) as usize) + RESULTS_LEN + 1)
    |             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ help: remove these parentheses
    |
    = note: `#[warn(unused_parens)]` on by default

    Finished dev [unoptimized + debuginfo] target(s) in 2.32s

Docs are not visible for the crate. https://docs.rs/crate/lpc55-hal/0.0.3/builds