probe-rs: probe-rs run fails on nrf9160

Describe the bug When I run probe-rs run for the nrf9160, it erases and flashes just fine. But after that finishes it should start the RTT output, however, I get the following error:

Error: This capability has not yet been implemented for this architecture: vector catch

This is both on 0.20 and the master version (as of writing).

It seems this has to do with the new vector catching feature. I took a look at it and this error message should only be printed when the default function of the CoreInterface trait is hit.

The nrf9160 does have a custom sequence, but it doesn’t look like that would be the problem…

Desktop (please complete the following information):

Linux (Ubuntu 22 LTS)

About this issue

Original URL
State: closed
Created a year ago
Comments: 20 (20 by maintainers)

Most upvoted comments

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!

jonathanpallant on Sep 19, 2023

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

diondokter on Aug 1, 2023

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 on Sep 13, 2023

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.

noppej on Sep 13, 2023

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

diondokter on Aug 4, 2023