software_init_hook bug has resurfaced, again:
This will only work on mbed OS5 devices (not OS2, like Pokitto)
@x-labz Success!!!
Compiled in Platformio, running on hardware:
But this solution required me to physically change the PIO package files.
I will look for a more elegant solution tomorrow
NOPE
Interrupt problems (hangs when button is pressed).
This is because of another reintroduced bug. I know where it is.
Until tomorrow.
3 Likes
Wow, looks awesome!!! 
Let me know if I need to change anything in the environment. At the moment my platform.io has the version 4.2.0 of mbed.
1 Like
Do you want to know the edits to the package files or do you want to wait for an automatic fix in the form of a python script?
Just had chance to. It works perfectly.
A tad slow, but that’s the only problem and I kind of expected that.
In case any of this helps:
Verbose mode can be enabled via `-v, --verbose` option
CONFIGURATION: https://docs.platformio.org/page/boards/nxplpc/lpc11u68.html
PLATFORM: NXP LPC 3.4.1 > LPCXpresso11U68
HARDWARE: LPC11U68 50MHz, 36KB RAM, 256KB Flash
DEBUG: Current (cmsis-dap) On-board (cmsis-dap) External (blackmagic, jlink)
PACKAGES: framework-mbed 5.50904.1 (5.9.4), toolchain-gccarmnoneeabi 1.70201.0 (7.2.1)
LDF: Library Dependency Finder -> http://bit.ly/configure-pio-ldf
LDF Modes: Finder ~ chain, Compatibility ~ soft
Found 26 compatible libraries
Scanning dependencies...
Dependency Graph
|-- <Pokitto> 0.0.5
Checking size .pio\build\pokitto\firmware.elf
Memory Usage -> http://bit.ly/pio-memory-usage
DATA: [======== ] 79.8% (used 29416 bytes from 36864 bytes)
PROGRAM: [== ] 19.4% (used 50740 bytes from 262144 bytes)
========================================= [SUCCESS] Took 2.49 seconds =========================================
And according to PIO Home I’m on Home 2.3.2 and Core 4.0.3, and my NXP LPC is 3.4.1.
Although now I think about it, I the pokitto_update_ld.py script broke a little while back because they changed something that caused env['PIOHOME_DIR'] to stop functioning properly.
They’ve probably changed it but I never got round to checking what the replacement was and fixing it.
(Partly because I assumed not many people were still using PlatformIO,
and partly because nobody else seemed to have noticed or complained.)
I just posted an issue about this on their GitHub, but I don’t know how soon I’ll get a reply.
Edit
The reply to my issue was brief, but almost instant.
Basically 'PIOHOME_DIR' is now 'PROJECTCORE_DIR'.
Edit
After a few false starts, here’s a PR:
Hopefully this new way of getting the home address will be more future-proof.
I think you are using an older nxplpc platform. Thats why it works. Have you tried updating?
If it’s probably going to break things, is there really any benefit to doing so?
Also check my edits to the above comment.
It seems your post happened while I was editing and my browser didn’t notice until afterwards.
Well, the problem comes with new users. Platformio will automatically pull the latest framework.
The latest framework introduces a new error:
So your solution does not work for the latest nxplpc framework, however it will also not work for the workaround (as given above), because if you do this: platform = nxplpc@3.5.0 to specify an older revision of the framework, that framework will not be the default directory, which means the necessary files do not get patched.
IMHO the solution should be such that anyone starting from fresh install off PIO will get it to compile. This is not the case right now.
And I fully realize this is not your fault in any way. The constantly changing, uncontrollable PIO environment is really beginning to get to me. I am getting tired of fixing the same issues over and over.
My ‘solution’ is absolutely nothing to do with the compilation problem, it’s an entirely separate issue.
The .ld file download script has been failing because apparently the env key that I was using was an ‘internal’ thing that has since been changed and might be changed again because it’s (I presume) not part of the public API.
My PR fixes that problem by using something I have been assured is more stable.
That can probably be sorted, but I probably won’t look into that today.
If I’m reading it correctly that issue seems to suggest that the problem is actually with mbed-cli rather than PlatformIO.
I think the only thing we can do to fix PlatformIO is to either introduce a custom platform,
or to contact the people who maintain the NXP platform and see if they can support us properly somehow.
If this keeps being a problem I might going to look into finding a way to build on Visual Studio without PlatformIO.
In all honesty it’s VSCode I like rather than PlatformIO.
If there’s a better alternative to PlatformIO that can work with at least VSCode and perhaps Atom and/or Emacs then I’d switch to that in a heartbeat.
Ideally using something other than make though,
because make support for Windows isn’t the best.
(Using make on Windows involves installing an oversized framework like MinGW or GNUWin32 and nobody wants to do that unless they’re Linux crazy).
It might even be possible to work parts of Femto into a standalone compilation system and integrate that with other editors.
1 Like
is this CRC fix this solution: [Solved] Using PlatformIO for compilation
or another workaround needed?
The fix is to fix the .ld linker file and the Startup_LPC11U6x.c file. I will post fixed versions / howto here later today.
The CRC is not the only issue. The issue is the bone-idle maintainers of the nxplpc platform.
1 Like
In fairness they’ve got 60 repositories to maintain between presumably just 2 people.
I think it’s more a case of being spread too thinly more than anything else.
I.e. having too much work for too few people.
Also NXPLPC seems to be one of the less popular platforms so it’s not that surprising that they’d prioritise AVR, SAM and Teensy.