It has: you can encrypt your code, store a decryption key in OTP, and decrypt into RAM. Or if your code is small and unchanging enough, store it directly in OTP.
I guess you are very serious about competing with industrial MCU’s.
We had to use a 2040 shortly after it came out because it was impossible to get STM32’s. Our customer accepted the compromise provided we replaced all the boards (nearly 1000) with STM32 boards as soon as the supply chain normalized.
I hope to also learn that you now have proper support for development under Windows. Back then your support engineers were somewhat hostile towards Windows-based development (just learn Linux, etc.). The problem I don’t think they understood was that it wasn’t a case of not knowing Linux (using Unix before Linux existed). A product isn’t just the code inside a small embedded MCU. The other elements that comprise the full product design are just as important, if not more. Because of this and other reasons, it can make sense to unify development under a single platform. I can’t store and maintain VM’s for 10 years because one of the 200 chips in the design does not have good support for Windows, where all the other tools live.
Anyhow, I explained this to your engineers a few years ago. Not sure they understood.
I have a project that I could fit these new chips into, so long as we don’t have to turn our workflow upside down to do it.
I will when I get a break. I'll bring-up our old RP2040 project and see what has changed.
I remember we had to use either VSC or PyCharm (can't remember which) in conjunction with Thonny to get a workable process. Again, it has been a few years and we switched the product to STM32, forgive me if I don't recall details. I think the issue was that debug communications did not work unless we used Thonny (which nobody was interested in touching for anything other than a downloader).
BTW, that project used MicroPython. That did not go very well. We had to replace portions of the code with ARM assembler for performance reasons, we simply could not get efficient communications with MicroPython.
Thanks again. Very much a fan. I mentored our local FRC robotics high school team for a few years. Lots of learning by the kids using your products. Incredibly valuable.
I was reading in I believe the Register article that yes, that's one of the protections they've tested... will be interesting to see if anyone can break it this month!
You can certainly do that, sure, but any Cortex-M MCU can do that, and plenty of others have hardware AES acceleration that would make the process much less asinine.
Also, 520K of RAM wouldn't be enough to fit a the whole application + working memory for any ARM embedded firmware I've worked on in the last 5 years.
To my recollection, every piece of Cortex-M firmware I've worked on professionally in the last 5 years has had at least 300K in .text on debug builds, with some going as high as 800K. I wouldn't call anything I've worked on in that time "atypical." Note that these numbers don't include the bootloader - its size isn't relevant here because we're ramloading.
If you're ram-loading encrypted firmware, the code and data have to share RAM. If your firmware is 250K, that leaves you with 270K left. That seems pretty good, but remember that the 2040 and 2350 are dual-core chips. So there's probably a second image you're loading into RAM too. Let's be generous and imagine that the second core is running something relatively small - perhaps a state machine for a timing-sensitive wireless protocol. Maybe that's another 20K of code, and 60K in data. These aren't numbers I pulled out out of my ass, by the way - they're the actual .text and .data regions used by the off-the-shelf Bluetooth firmware that runs on the secondary core of an nRF5340.
So now you're down to 190K in RAM available for your 250K application. I'd call that "normal," not huge at all. And again, this assumes that whatever you're running is smaller than anything I've worked on in years.
> Also, 520K of RAM wouldn't be enough to fit a the whole application + working memory for any ARM embedded firmware I've worked on in the last 5 years.
what are you smoking? I have an entire decstation3100 system emulator that fits into 4K of code and 384bytes of ram. I boot palmos in 400KB of RAM. if you cannot fit your "application" into half a meg, maybe time to take up javascript and let someone else do embedded?
I'm smoking multiprotocol wireless systems for industrial, medical, and military applications. To my recollection, the very smallest of those was around 280K in .text, and 180K in .data. Others have been 2-3x larger in both areas.
I would sure hope a decstation3100 emulator is small. After all, it's worthless unless you actually run something within the emulator, and that will inevitably be much larger than the emulator itself. I wouldn't know, though. Believe it or not, nobody pays me to emulate computers from 1978.
So you make hardware costing dozens of thousands of dollars and brag about memory on 5$ chip?
That explains a lot why so many medical and industrial (I haven’t touch military hardware) are so badly designed, with some sad proprietary protocols and dead few months after warranty passes. Today I’ve learned!
