Thanks for this PR!
Replacing hprintln with defmt is a good thing IMO.
Do we still need (defmt-)rtt when we have defmt?
As for the QEMU issue, I will test it tomorrow morning (although run-example-on-qemu passed on CI, so I think it will be fine).

FYI, will test tomorrow instead since I cannot compile the psa backend in my M1 machine.

If replacing hprintln with defmt is fine, I will update this PR from draft to ready for review!

Do we still need defmt-rtt when we have defmt?

Yes, without defmt-rtt I was getting a bunch of linking issues like:

rust-lld: error: undefined symbol: _defmt_acquire
rust-lld: error: undefined symbol: _defmt_release
rust-lld: error: undefined symbol: _defmt_write

I found a issue that the solution was to keep the use defmt_rtt as _; to add a global logger

Let me know how the QEMU test goes!

I tried here, and I it indeeds gets stuck at

    Finished `dev` profile [unoptimized + debuginfo] target(s) in 0.83s
     Running `qemu-system-arm -cpu cortex-m3 -machine lm3s6965evb -nographic -semihosting-config enable=on,target=native -kernel /home/gfedrech/Developer/inria/dev/lakers-FORK/target/thumbv7m-none-eabi/debug/lakers-no_std`
Timer with period zero, disabling

On the other hand, the version on main prints:

$ cargo run  --no-default-features --features="crypto-psa" --release
    Finished `release` profile [optimized] target(s) in 4.36s
     Running `qemu-system-arm -cpu cortex-m3 -machine lm3s6965evb -nographic -semihosting-config enable=on,target=native -kernel /home/gfedrech/Developer/inria/dev/lakers-FORK/target/thumbv7m-none-eabi/release/lakers-no_std`
Timer with period zero, disabling
Hello, lakers!
Test test_new_initiator passed.
Test test_p256_keys passed.
Test test_prepare_message_1 passed.
Test test_handshake passed.
All tests passed.

(although I just realised that the QEMU version doesn't work without the --release flag, even on main).

Have you tried using defmt-semihosting as mentioned here? It seems it should be used for testing with QEMU.

@geonnave Thanks for the defmt-semihosting suggestion. I tried it out, but it appears that in addition to adding defmt-semihosting, I need to integrate a printer, a decoder, and a parser to properly process and display the data from QEMU.

This is how I understood they do in their example. Without this printer/decoder/parser combo, the log output appears as gibberish.

Because of this, I reverted to using use cortex_m_semihosting::hprintln as info; for the QEMU case and updated the README to reflect these changes.

Let me know if you need any further adjustments!

Thanks, left an editorial comment. Can you also please update the relevant section in the main README?

Feel free to add me as collaborator in your fork, this way I can also push some changes when needed (like updating the README).

I also just noticed, could you rebase and use the scope: description pattern in the commit messages? Just to keep the same pattern as the rest of the commits. (basically just add the example: prefix to all commits)

I also just noticed, could you rebase and use the scope: description pattern in the commit messages? Just to keep the same pattern as the rest of the commits. (basically just add the example: prefix to all commits)

Sorry about that! I didn't knew you guys were using conventional commit messages. I've rebased the branch and updated the commit messages. Thanks for the heads up!