Add support for EFR32MG24

[jaxter184]

Add support for EFR32MG24

[corecode]

Probably much easier to sniff on the SWD pins.  I tried sniffing JLink messages, but at least JLinkExe uses undocumented USB messages, so it was tedious to figure out what was going on.

…

On 26/07/2023 20:06, jaxter184 wrote: did you read these application notes on their debug interface locking and security? I haven't seen these yet! I'll give them a look, thanks. Some sort of security memory protection shenanigan is top on my list of suspects at the moment. It might be worth comparing the values in the generated target yaml to those in the docs There aren't any blantant errors, but I'll definitely do a closer comparison at some point. Are you able to run probe-rs in a debugger, and trace back to where exactly the error is happening? Hopefully this isn't too nooby of a question, but since the program doesn't panic (at least I think that's what's going on?), what's the easiest way to get a trace of where the error is happening? Usually I would use the |backtrace| gdb command, but since it just exits, I think that wouldn't work? The only other option I can think of is to set break points and/or step through carefully. Also, I was able to get the chip flashed using Silicon Labs' Simplicity Commander tool <https://www.silabs.com/documents/public/user-guides/ug162-simplicity-commander-reference-guide.pdf>. I couldn't get the GPIOs working (probably something wrong with my PAC), but it correctly identifies RTT memory, so I think it's flashing correctly? Maybe it'd help to sniff the USB messages or something and see what the differences are? — Reply to this email directly, view it on GitHub <#1700 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AABLOOYJSJTFOG5HYWXBS3TXSFMAVANCNFSM6AAAAAA2XYH3OA>. You are receiving this because you were mentioned.Message ID: ***@***.***>

[noppej]

So not having a EFM32 to debug with, I'm looking at the code paths, and the two probe-rs run errors look related, with slight differences because the first one follows code to flash the target, and the second is a straight-up attach.

Perhaps you can reach out to @corecode who implemented the custom sequence ... in case he has some pointers.

Also, did you read these application notes on their debug interface locking and security?

• https://www.silabs.com/documents/public/application-notes/an1303-efr32-dci-swd-programming.pdf
• https://www.silabs.com/documents/public/application-notes/an1190-efr32-secure-debug.pdf

Finally, target-gen relies on information in the CMSIS-PACK to generate memory addresses and other values, but we've all seen examples where CMSIS-PACK files have bugs. It might be worth comparing the values in the generated target yaml to those in the docs and make sure there are no obvious discrepencies.

Are you able to run probe-rs in a debugger, and trace back to where exactly the error is happening?

[corecode]

I don't have openocd working for my efr32bg22 - there is a fork somewhere on github that adds support for the series 2 chips, but I didn't bother. JLinkGDBServer works. I recently used probe-rs and it worked to flash, but failed on monitor reset.

[jaxter184]

did you read these application notes on their debug interface locking and security?

I haven't seen these yet! I'll give them a look, thanks. Some sort of security memory protection shenanigan is top on my list of suspects at the moment.

It might be worth comparing the values in the generated target yaml to those in the docs

There aren't any blantant errors, but I'll definitely do a closer comparison at some point.

Are you able to run probe-rs in a debugger, and trace back to where exactly the error is happening?

Hopefully this isn't too nooby of a question, but since the program doesn't panic (at least I think that's what's going on?), what's the easiest way to get a trace of where the error is happening? Usually I would use the backtrace gdb command, but since it just exits, I think that wouldn't work? The only other option I can think of is to set break points and/or step through carefully.

Also, I was able to get the chip flashed using Silicon Labs' Simplicity Commander tool. I couldn't get the GPIOs working (probably something wrong with my PAC), but it correctly identifies RTT memory, so I think it's flashing correctly? Maybe it'd help to sniff the USB messages or something and see what the differences are?

[noppej]

what's the easiest way to get a trace of where the error is happening?

If you can run probe-rs in a debugger, you can put a breakpoint on the error message and look at the stack trace, and/or step through the code immediately before the error.

I use VSCode with LLDB for debugging the probe-rs code.

[corecode]

would it be possible for somebody to document the logging environment variables to see which SWD/AP transactions are happening?  i tried probe-run with very verbose, and there is a lot of chatter which makes it difficult to follow.

…

On 26/07/2023 20:19, JackN wrote: what's the easiest way to get a trace of where the error is happening? If you can run probe-rs in a debugger, you can put a breakpoint on the error message and look at the stack trace, and/or step through the code immediately before the error. — Reply to this email directly, view it on GitHub <#1700 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AABLOOYQN74WFE4KOSRYS23XSFNTPANCNFSM6AAAAAA2XYH3OA>. You are receiving this because you were mentioned.Message ID: ***@***.***>

[noppej]

I apologize if this is stating the obvious, but have you tried limiting to just the module you suspect ... e.g. RUST_LOG="trace, probe_rs::probe"

[noppej]

Also, I know @Yatekii created this log viewer, but I haven't spent much time with it ... I prefer good old grep LOL

[jaxter184]

I finally got around to getting a debug trace:

Thread 1 "probe-rs" hit Breakpoint 4, probe_rs::probe::jlink::arm::parse_swd_response (
    response=&[bool](size=56) = {...}, direction=probe_rs::probe::jlink::arm::TransferDirection::Read)
    at probe-rs/src/probe/jlink/arm.rs:795
795	        return Err(DapError::FaultResponse);
(gdb) bt
#0  probe_rs::probe::jlink::arm::parse_swd_response (response=&[bool](size=56) = {...},
    direction=probe_rs::probe::jlink::arm::TransferDirection::Read) at probe-rs/src/probe/jlink/arm.rs:795
#1  0x00005555570a0ad8 in probe_rs::probe::jlink::arm::perform_swd_transfers<probe_rs::probe::jlink::JLink> (
    probe=0x55555974a790, transfers=&mut [probe_rs::probe::jlink::arm::DapTransfer](size=2) = {...})
    at probe-rs/src/probe/jlink/arm.rs:332
#2  0x00005555570a439a in probe_rs::probe::jlink::arm::perform_transfers<probe_rs::probe::jlink::JLink> (
    probe=0x55555974a790, transfers=&mut [probe_rs::probe::jlink::arm::DapTransfer](size=1) = {...}, idle_cycles=2)
    at probe-rs/src/probe/jlink/arm.rs:496
#3  0x0000555557445b63 in probe_rs::probe::jlink::arm::{impl#5}::raw_read_register<probe_rs::probe::jlink::JLink> (
    self=0x55555974a790, port=probe_rs::architecture::arm::traits::PortType::AccessPort, address=12)
    at probe-rs/src/probe/jlink/arm.rs:954
#4  0x00005555575ee5d7 in probe_rs::architecture::arm::communication_interface::{impl#14}::read_raw_ap_register (
    self=0x555559725090, ap=..., address=12) at probe-rs/src/architecture/arm/communication_interface.rs:689
#5  0x00005555575d28e1 in probe_rs::architecture::arm::ap::{impl#1}::read_ap_register<probe_rs::architecture::arm::communication_interface::ArmCommunicationInterface<probe_rs::architecture::arm::communication_interface::Initialized>, probe_rs::architecture::arm::ap::memory_ap::MemoryAp, probe_rs::architecture::arm::ap::memory_ap::DRW> (self=0x555559725090,
    port=...) at probe-rs/src/architecture/arm/ap/mod.rs:145
#6  0x0000555557651189 in probe_rs::architecture::arm::memory::adi_v5_memory_interface::ADIMemoryInterface<probe_rs::architecture::arm::communication_interface::ArmCommunicationInterface<probe_rs::architecture::arm::communication_interface::Initialized>>::read_ap_register<probe_rs::architecture::arm::communication_interface::ArmCommunicationInterface<probe_rs::architecture::arm::communication_interface::Initialized>, probe_rs::architecture::arm::ap::memory_ap::DRW> (
    self=0x555559753b00, access_port=...) at probe-rs/src/architecture/arm/memory/adi_v5_memory_interface.rs:266
#7  0x0000555557652b1f in probe_rs::architecture::arm::memory::adi_v5_memory_interface::ADIMemoryInterface<probe_rs::architecture::arm::communication_interface::ArmCommunicationInterface<probe_rs::architecture::arm::communication_interface::Initialized>>::read_word_32<probe_rs::architecture::arm::communication_interface::ArmCommunicationInterface<probe_rs::architecture::arm::communication_interface::Initialized>> (self=0x555559753b00, access_port=..., address=4)
    at probe-rs/src/architecture/arm/memory/adi_v5_memory_interface.rs:363
#8  0x0000555557673391 in probe_rs::architecture::arm::memory::adi_v5_memory_interface::{impl#3}::read_32<probe_rs::architecture::arm::communication_interface::ArmCommunicationInterface<probe_rs::architecture::arm::communication_interface::Initialized>> (self=0x555559753b00, address=4, data=&mut [u32](size=1) = {...})
    at probe-rs/src/architecture/arm/memory/adi_v5_memory_interface.rs:910
#9  0x000055555764ddde in probe_rs::architecture::arm::memory::adi_v5_memory_interface::ArmProbe::read_word_32<probe_rs::architecture::arm::memory::adi_v5_memory_interface::ADIMemoryInterface<probe_rs::architecture::arm::communication_interface::ArmCommunicationInterface<probe_rs::architecture::arm::communication_interface::Initialized>>> (
    self=0x555559753b00, address=4) at probe-rs/src/architecture/arm/memory/adi_v5_memory_interface.rs:32
#10 0x000055555704c5cf in probe_rs::architecture::arm::sequences::efm32xg2::{impl#1}::reset_catch_set (
    self=0x555559711e10, core=..., _core_type=probe_rs_target::chip_family::CoreType::Armv8m, _debug_base=...)
    at probe-rs/src/architecture/arm/sequences/efm32xg2.rs:35
#11 0x0000555557277b7f in probe_rs::architecture::arm::core::armv8m::{impl#1}::reset_catch_set (self=0x55555974fd60)
    at probe-rs/src/architecture/arm/core/armv8m.rs:446
#12 0x0000555557273f9b in probe_rs::architecture::arm::core::armv8m::{impl#1}::reset_and_halt (self=0x55555974fd60,
    _timeout=...) at probe-rs/src/architecture/arm/core/armv8m.rs:230
#13 0x0000555557031338 in probe_rs::core::Core::reset_and_halt (self=0x7ffffffe6650, timeout=...)
    at probe-rs/src/core.rs:412
#14 0x00005555572a8c19 in probe_rs::flashing::flasher::Flasher::load (self=0x7ffffffeaf00)
    at probe-rs/src/flashing/flasher.rs:134
#15 0x00005555572a5bec in probe_rs::flashing::flasher::Flasher::new (session=0x7fffffff8298, core_index=0,
    raw_flash_algorithm=0x7fffffff0a60, progress=...) at probe-rs/src/flashing/flasher.rs:104
#16 0x00005555574de61d in probe_rs::flashing::loader::FlashLoader::commit (self=0x7fffffff8d30, session=0x7fffffff8298,
    options=...) at probe-rs/src/flashing/loader.rs:344
#17 0x0000555555ac9a32 in probe_rs::util::flash::run_flash_download (session=0x7fffffff8298, path=...,
    download_options=0x7fffffffcce0, probe_options=0x7fffffff8350, loader=..., do_chip_erase=false)
    at probe-rs/src/bin/probe-rs/util/flash.rs:144
#18 0x0000555555f61894 in probe_rs::cmd::run::Cmd::run (self=..., run_download=true, timestamp_offset=...)
    at probe-rs/src/bin/probe-rs/cmd/run.rs:67
#19 0x0000555555ca4132 in probe_rs::main () at probe-rs/src/bin/probe-rs/main.rs:256
#20 0x0000555555c488eb in core::ops::function::FnOnce::call_once<fn() -> core::result::Result<(), anyhow::Error>, ()> ()
    at /rustc/90c541806f23a127002de5b4038be731ba1458ca/library/core/src/ops/function.rs:250
#21 0x0000555555ed5bbe in std::sys_common::backtrace::__rust_begin_short_backtrace<fn() -> core::result::Result<(), anyhow::Error>, core::result::Result<(), anyhow::Error>> (f=0x555555ca2760 <probe_rs::main>)
    at /rustc/90c541806f23a127002de5b4038be731ba1458ca/library/std/src/sys_common/backtrace.rs:134
#22 0x0000555555d78d01 in std::rt::lang_start::{closure#0}<core::result::Result<(), anyhow::Error>> ()
    at /rustc/90c541806f23a127002de5b4038be731ba1458ca/library/std/src/rt.rs:166
#23 0x0000555557d02c3e in core::ops::function::impls::{impl#2}::call_once<(), (dyn core::ops::function::Fn<(), Output=i32> + core::marker::Sync + core::panic::unwind_safe::RefUnwindSafe)> () at library/core/src/ops/function.rs:287
#24 std::panicking::try::do_call<&(dyn core::ops::function::Fn<(), Output=i32> + core::marker::Sync + core::panic::unwind_safe::RefUnwindSafe), i32> () at library/std/src/panicking.rs:485
#25 std::panicking::try<i32, &(dyn core::ops::function::Fn<(), Output=i32> + core::marker::Sync + core::panic::unwind_safe::RefUnwindSafe)> () at library/std/src/panicking.rs:449
#26 std::panic::catch_unwind<&(dyn core::ops::function::Fn<(), Output=i32> + core::marker::Sync + core::panic::unwind_safe::RefUnwindSafe), i32> () at library/std/src/panic.rs:140
#27 std::rt::lang_start_internal::{closure#2} () at library/std/src/rt.rs:148
#28 std::panicking::try::do_call<std::rt::lang_start_internal::{closure_env#2}, isize> ()
    at library/std/src/panicking.rs:485
#29 std::panicking::try<isize, std::rt::lang_start_internal::{closure_env#2}> () at library/std/src/panicking.rs:449
#30 std::panic::catch_unwind<std::rt::lang_start_internal::{closure_env#2}, isize> () at library/std/src/panic.rs:140
#31 std::rt::lang_start_internal () at library/std/src/rt.rs:148
#32 0x0000555555d78cda in std::rt::lang_start<core::result::Result<(), anyhow::Error>> (
    main=0x555555ca2760 <probe_rs::main>, argc=5, argv=0x7fffffffdab8, sigpipe=0)
    at /rustc/90c541806f23a127002de5b4038be731ba1458ca/library/std/src/rt.rs:165
#33 0x0000555555cab1de in main ()
#34 0x00007ffff7423cd0 in ?? () from /usr/lib/libc.so.6
#35 0x00007ffff7423d8a in __libc_start_main () from /usr/lib/libc.so.6
#36 0x0000555555a33f35 in _start ()

(a recording of me collecting the trace. the actual trace is about halfway through the recording.)

My untrained eye doesn't really see anything here that looks like it'll directly help with this problem. I think my next step is going to be to look at the SWD lines through a logic analyzer and compare it to Simplicity Commander's output.