ARM stack
Rick Murray (539) 13840 posts |
Re. http://embeddedgurus.com/state-space/tag/arm-cortex-m/
And:
I don’t know about the specifics of the Cortex-M… But if your stack is in early memory and it writes downwards, don’t you risk an even worse situation as you trash the processor vectors if they are based at &0? Surely rather than a really ugly hack like shifting the stack around to avoid stomping on something “important”, it might be a much better idea to periodically check the stack pointer (function entry?) to make sure it is within an acceptable range? |
Steve Pampling (1551) 8170 posts |
Well, the man quotes the NRA (a lot) and it’s not like they don’t know how to keep people safe is it? Let’s consider it in a more friendly fashion – if you play a ball game and regularly put the ball out of the field of play, maybe, just maybe you need a bigger field of play. In the cited case the report clearly highlights Toyota not having accounted for all uses of the stack and therefore made the stack space way too small and didn’t do run time stack monitoring. The guy isn’t too bright, it’s a size issue not direction. I bet the report summarised with a statement that a larger stack and monitoring would have prevented the problem. 1 Possibly a silly idea with NRA members |
Rick Murray (539) 13840 posts |
Yes, I noticed. The first time I read, I was looking at the technical aspects and scratching my head over the supposed “solution”.
Exactly. That and careful use of the stack. I guess the guy didn’t grow up in the eighties or else he might have remembered that without hacks, the 6502 offers a fixed location for the stack. Fair enough, you can’t go out of bounds when you are restricted to page 1, but on the other hand 256 bytes was all you got. Yet… Yet… Somehow (magic?) entire operating systems existed. I don’t know the technical aspects of the situation (didn’t read the report) but a quick calculation shows that an 8KiB stack would have been two thousand words. 16KiB, four thousand. I have not monitored RISC OS’ use of the stack, but doesn’t this sound like a runaway loop that continually pushes to the stack without later pulling?
I think somebody mentioned that in one of the comments and it was dismissed as taking time to execute the instructions. Well, gee, let’s see – we can take a few nanoseconds to load and check the stack pointer or we can just not bother and set up our system in a weird way to use hardware exceptions to deal with this while running the risk that we may stomp across hardware vectors so instead of trashing process pointers it’ll be a system freeze. Hope you have a hardware watchdog… I liked the bit about the idea that a full system reset while travelling would take place in… What was it, eleven yards? Yeah, dude, if the system needs to reset at any point while the vehicle is moving, something is very seriously wrong with the design. |
Steve Pampling (1551) 8170 posts |
11 feet rather than yards. Not just with the design, but also with the thinking that leads to “turn it off and back on again” instead of “find the error and fix it” Mind you the website name puts my back up immediately. They are happy posting on a site where they effectively self declare as gurus? It’s like the self declared “experts” who are nothing of the sort. Can you imagine Justin or Sophie declaring themselves to be gurus? 1 It got moved to a server so I have no idea whether it is still running. AV software is not a panacea so things like this are handy. |
Jon Abbott (1421) 2651 posts |
It’s on the right track…place an unmapped page below the stack so you get a processor abort on overflow. Placing it low memory however adds complications. I lost interest at the lawsuit section. |