probe-rs run fails on nrf9160

[diondokter]

probe-rs run fails on nrf9160

[diondokter]

I can maybe justify it enough to spend a bit of time on it this friday

[jonathanpallant]

I have a spare Nuvoton Cortex-M23 board and I can hand it to someone at EuroRust. It cost me £100 with all the import fees and shipping from China, but then I never used it :( Free to a good home!

[diondokter]

I tried to look up what these extensions are.

Main: A chip can be baseline or mainline. Baseline has compatibility with armv6m and mainline has compatibility with armv7m. I think all m23 chips are baseline and all m33 chips are mainline.

In my experience, the m33 seems more common. However, the m23 is definitely out there.
Seemingly the only difference for vector catch seems to be that the DEMCR register is slightly different.

Security: This is just another word for Trustzone according to the reference manual. I've yet to come across an armv8m chip without Trustzone. If we want to KISS it, we should make sure this is supported. However, since most people don't seem to be using many features of it, we could easily get away with not tracing across secure-nonsecure bounds.

In any case, with the security extension it looks like the chip is a bit more strict in when it actually catches a vector. But nothing seems overly strict to me with my limited view, so supporting with and without extension should be doable. The not tracing across secure bounds is up to the tracing code.

Debug: It's only mentioned once in the reference manual, only stating its existance. I have no idea what this is and what it does.

TLDR: KISS seems good to me, but most realistic gains are in not having to implement trustzone for tracing

[noppej]

I'm happy to help - this is quite a journey of learning about the Armv8-M processor architecture, probe-rs, and how debugging toolchains work in general. It's also been a good excuse for me to dive into a serious Rust code repository :)

I have a branch that is possibly ready for PR at https://github.com/sullivanmj/probe-rs/tree/feature/vector-catch-armv8m. In this branch I added stack unwinding for armv8m targets. The secret sauce is in the ExceptionInterface::calling_frame_registers for armv8m. The stacks that I unwound appeared to look correct, aside from seeing the two frames similar to the ones that @diondokter mentioned above (frames 11 and 12). I have no idea if those are normally seen with probe-rs or not, so I don't know if that's problematic from the user's perspective or not.

I also added vector catch for armv8m targets. It can catch a SecureFault. The default behavior when using VectorCatchCondition::All for armv8m targets that implement the Security Extension is to catch SecureFaults in addition to HardFaults and CoreResets.

There are a few reasons I say that it is possibly ready for PR. The main reason is that it is not extensively tested. I am having a hard time testing this due to a few things. First, I do not have much of a TrustZone test application for my particular target, written in Rust. I suppose I could use the elfs from some C example for my particular target and the stack unwinding would still work the same.

But, even if I did, there is #310, which is preventing me from flashing more than one elf at a time. I was able to program a secure elf, at least, by adding an NVM node adjacent to the existing one for my target, with the flash address range aliased to the secure memory region. Side note - probe-rs handled this part quite nicely. I was able to switch back and forth between programming secure and non-secure elfs without having to edit/rebuild each time.

I suspect that to properly support TrustZone, the above-mentioned issue would need to be completed, and probe-rs would probably need to allow you to load multiple elfs, which in addition to both being programmed at launch, would both be searched for debug symbols.

Unless there is some other way to do this more extensive testing, I'm not sure of a great way to test getting stack traces that cross security domains more than just from catching a SecurityFault that is raised from code executing in the non-secure domain.

With all of that said, does this seem like a decent stopping point for a PR for this particular issue, assuming the code can be more thoroughly tested within the current constraints?

Perfect ... looking forward to the PR.
PS. I'm getting my own (first for me) Armv8-m board later this week, so have a personal gratitude for your work here.

[Yatekii]

Thanks a lot! I think you should just PR this and we can discuss on the PR :) We generally rather merge a new feature that is not 100% complete but adds value nonetheless and iterate later :) I don't see a lot of folks using TrustZone, so I doubt it's a requirement to have it supported properly for now :)

[Yatekii]

Uff, this is bad. So Vector catch is used for printing a stacktrace in probe-rs run, but it is only implemented for armv6 and v7. For v8 it is missing and the nRF9169 is a v8 core. This is easily fixable by making the stacktrace readout optional. But it would be better to actually implement it for v8 (which might be a bit more elaborate but very doable).

[diondokter]

So it looks to me like all the bits are still the same compared to armv7m. If I copy the armv7m bits, things seem to work? diondokter@cff61a6

This gives me this stack trace:

Frame 0: "HardFault handler. Cause: Escalated UsageFault (Undefined instruction)." @ 0x00052b82
Frame 1: __udf @ 0x00052a32 inline
       ./asm/lib.rs:48:1
Frame 2: __udf @ 0x0000000000052a32
       ./asm/lib.rs:51:17
Frame 3: udf @ 0x000522fa
       C:\Users\diond\.cargo\registry\src\index.crates.io-6f17d22bba15001f\cortex-m-0.7.6\src/asm.rs:43:5
Frame 4: {async_fn#0} @ 0x000522f0
       C:\Repos\nrf91-2.0.1-test\src/main.rs:37:5
Frame 5: drop_in_place<nrf9160_rust_starter::run::{async_fn_env#0}> @ 0x000522c8 inline
       C:/rustc/871b5952023139738f72eba235063575062bc2e9/library/core/src/ptr/mod.rs
Frame 6: {async_fn#0} @ 0x00000000000522c8 inline
       C:\Repos\nrf91-2.0.1-test\src/main.rs:30:11
Frame 7: <unknown function @ 0x000522c8> @ 0x00000000000522a4
       C:\Users\diond\.cargo\git\checkouts\embassy-9312dcb0ed774b29\d8c7c3f\embassy-executor\src\raw/mod.rs:164:15
Frame 8: <unknown function @ 0x000525fa> @ 0x000525fa
       C:\Users\diond\.cargo\git\checkouts\embassy-9312dcb0ed774b29\d8c7c3f\embassy-executor\src\raw/util.rs:54:9
Frame 9: __cortex_m_rt_main @ 0x0005038e
       C:\Repos\nrf91-2.0.1-test\src/main.rs:18:1
Frame 10: __cortex_m_rt_main_trampoline @ 0x00050378
       C:\Repos\nrf91-2.0.1-test\src/main.rs:18:1
Frame 11: <unknown function @ 0x00050180> @ 0x00050180
Frame 12: <unknown function @ 0x00050180> @ 0x00050180

Aside from the improper path separator and the last two frames, it looks just fine.

That said, do we know what the differences are between v7 and v8?

[noppej]

For one thing, the EXC_RETURN that drives this, has different values. Armv8m also has an optional "Security Extension" which the docs says modifies exception behaviour. Based on the fact that I don't have a Armv8m device to develop and test on, I figured it is better to leave it unimplemented, vs. give untested results :)
PS. I also have not verified the bitfield mapping and enum values of the exception registers.

[diondokter]

Thanks for the info! Afaik, the only exception stuff added for security is the secure fault. I'll look friday if I can see some problems when it's in secure mode

[noppej]

Cool. If you wish, I am also willing to PR changes based on the documentation ...and then hand the code to you for testing / validation.

…

________________________________ From: Dion Dokter ***@***.***> Sent: August 2, 2023 11:59 AM To: probe-rs/probe-rs ***@***.***> Cc: JackN ***@***.***>; Comment ***@***.***> Subject: Re: [probe-rs/probe-rs] probe-rs run fails on nrf9160 (Issue #1709) Thanks for the info! Afaik, the only exception stuff added for security is the secure fault. I'll look friday if I can see some problems when it's in secure mode — Reply to this email directly, view it on GitHub<#1709 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/ABJJRNQXQN3AMQCXZ2CRSCLXTJ2NFANCNFSM6AAAAAA27PIFL4>. You are receiving this because you commented.Message ID: ***@***.***>

[diondokter]

@noppej that would be awesome! I've got an nrf9160 and an nrf5340, so only Nordic stuff for armv8m. But in theory that shouldn't matter

[noppej]

Cool. I am away from my dev machine until Tue next week, and will start working on it then. Casual reading suggests their are 3 extensions we could code for ... Main, Debug and Security. So, I might take the KISS approach, and focus on having a standard Armv8m implementation (no extensions), and give the stack trace for that, with an optional warning when an extension exists, warning the user that the stack trace may be incomplete. Thoughts?

[sullivanmj]

I ran into this on an STM32L562. Being new to rust, probe-rs, and the armv8m architecture, I don't think I could contribute code for this in any meaningful way, but would be happy to help with testing, if/when any PR is in progress or ready.

[noppej]

Realistically, I don't see myself working on this for the next month or two, but am happy to help someone get started on the probe-rs code base in general, and this functional area specifically.

[sullivanmj]

With an offer for support like that, I can at least take a look and see if I'm feeling ambitious enough to give it a go. If you could point me to the implementation for armv7 and/or anything else you think might be relevant, I can take a look and reference the armv8 manual to see if it's something I think I can realistically take on.

[sullivanmj]

I found #1592. I'll take a look and see if I can figure out what needs to be done. If you've got any information that isn't going to be obvious from that PR, I'd be glad to hear it :)

Edit: OK, looked at @diondokter's commit, and was able to both run and debug with probe-rs on the STM32L562. I also could get a stack trace after causing a HardFault, once I added their implementation of ExceptionInterface for armv8.

It seems that the high-level tasks, at this point, are:

• Move that code into a proper module at probe-rs/src/architecture/arm/core/exception_handling/armv8m.rs, along with whatever supporting changes are required to fill out that module
• As mentioned above, support getting a stack trace when using the features of the Security extension of the armv8m architecture
• Anything else?

I'll need to do some learning on TrustZone. I'm familiar with some of the features it offers, but haven't ever used it.

[noppej]

@sullivanmj Yes, if you look at #1665, this is where I introduced the probe-rs::core::ExceptionInterface. Implementing this for specific architectures is what allows the vector catch in #1592 to effectively unwind the stack when it encounters an exception.

As @diondokter pointed out, the mechanics are almost identical for Armv8m as it is for the existing Armv6m and Armv7m implementations. The differences comes in the interpretation of the various exception flags in the registers, so yes, I think your "high-level tasks" are a good place to start.

Thank you for tackling this :)

[sullivanmj]

I'm happy to help - this is quite a journey of learning about the Armv8-M processor architecture, probe-rs, and how debugging toolchains work in general. It's also been a good excuse for me to dive into a serious Rust code repository :)

I have a branch that is possibly ready for PR at https://github.com/sullivanmj/probe-rs/tree/feature/vector-catch-armv8m. In this branch I added stack unwinding for armv8m targets. The secret sauce is in the ExceptionInterface::calling_frame_registers for armv8m. The stacks that I unwound appeared to look correct, aside from seeing the two frames similar to the ones that @diondokter mentioned above (frames 11 and 12). I have no idea if those are normally seen with probe-rs or not, so I don't know if that's problematic from the user's perspective or not.

I also added vector catch for armv8m targets. It can catch a SecureFault. The default behavior when using VectorCatchCondition::All for armv8m targets that implement the Security Extension is to catch SecureFaults in addition to HardFaults and CoreResets.

There are a few reasons I say that it is possibly ready for PR. The main reason is that it is not extensively tested. I am having a hard time testing this due to a few things. First, I do not have much of a TrustZone test application for my particular target, written in Rust. I suppose I could use the elfs from some C example for my particular target and the stack unwinding would still work the same.

But, even if I did, there is #310, which is preventing me from flashing more than one elf at a time. I was able to program a secure elf, at least, by adding an NVM node adjacent to the existing one for my target, with the flash address range aliased to the secure memory region. Side note - probe-rs handled this part quite nicely. I was able to switch back and forth between programming secure and non-secure elfs without having to edit/rebuild each time.

I suspect that to properly support TrustZone, the above-mentioned issue would need to be completed, and probe-rs would probably need to allow you to load multiple elfs, which in addition to both being programmed at launch, would both be searched for debug symbols.

Unless there is some other way to do this more extensive testing, I'm not sure of a great way to test getting stack traces that cross security domains more than just from catching a SecurityFault that is raised from code executing in the non-secure domain.

With all of that said, does this seem like a decent stopping point for a PR for this particular issue, assuming the code can be more thoroughly tested within the current constraints?

[noppej]

The stacks that I unwound appeared to look correct, aside from seeing the two frames similar to the ones that @diondokter mentioned above (frames 11 and 12). I have no idea if those are normally seen with probe-rs or not, so I don't know if that's problematic from the user's perspective or not.

Yeah, those show up consistently ... I'm working on cleaning up stacktrace, but for now you can ignore them.

[noppej]

Unless there is some other way to do this more extensive testing, I'm not sure of a great way to test getting stack traces that cross security domains more than just from catching a SecurityFault that is raised from code executing in the non-secure domain.

I agree. We don't have to solve ALL the problems in this PR. Getting the basics working well is a good first step. I find it helps to document known limitations in the PR, so future contributors can see where to pick up the baton.