Probably an interrupt handler that ends up in a hardfault, or a system initialization stuck, such as waiting for PLL clock to lock
#and:
hardware debugging on PlatformIO is possible only by subscribing to “plus” subscription at 9,90$ per month.
For me this alone kills the platform.
I would rather get everything working on Ecclipse than waste more time on this.
But, since we’ve come such a long way, I will try my best to get this working also.
1 Like
#update
something is very wrong in the binary output by PlatformIO and I think it is still to do with the linking.
First value is supposed to be the SP (stack pointer) value at initialization. RAM1 runs from 0x1000 0000 to 0x1000 7FFF.
But 0x46C0B5F8 ?
Second value is supposed to be PC (program counter) at initialization, program memory starts from 0x0, and first instruction is usually at 0xFC after the interrupt table. 0xBC08BCF8 ?
So in other words: the processor sets the stack pointer to some godforsaken address in the 4GB address space and jumps to another idiotic address. No wonder it doesn’t run.
Turns out I have to write a custom framework & board manifest
Too much for tonight. Back tomorrow.
1 Like
if its that much of a pain i hope this is only a one time thing and it would just run on the other operating systems.
@adekto for me, the 9,90$ per month for HW debugging on Platformio is a killer.
You might reasonably argue, that HW debugging is not needed, but it is very, very, very useful (or what, @Hanski?)
I already have the CMSIS-DAP debugger running on a Pokitto, making Pokitto->Pokitto HW debugging possible (soon, I promise)
I am not so enthusiastic in steering the userbase to a solution that requires monthly subscription for a feature that comes for free in almost all ARM GCC IDE’s (and even in the Keil MDK Lite)
1 Like
Could we not use a separate hardware debugger?
If so we might be able to set up IDE extensions for using the hardware debugger on certain IDEs.
Not on platformio. The debug interface only comes up when you subscribe. (tried last night)
Ofcourse, you can gdb from command line but thats not exactly easy
I was thinking since it can run on VSCode or Atom that we could just get VSCode or Atom to use a separate debugger by hooking up an extension, rather than trying to do it through PlatformIO.
If PlatformIO prevents that somehow then that’s annoying.
I’m pretty sure VSCode extensions can run arbitrary commands on the command line so setting up a ‘gdb’ command should work unless the command has to be really complex.
(The commands called seem to be dictated by javascript or typescript from what I remember.)
When I’ve got more time I’ll see if I can get GCC running on its own with VSCode and doing the CRC thing as a post-build, or even Visual Studio or something.
(Personally I’m happy sticking with EmBitz but I feel sorry for the Mac and Linux users, so I’d like to try to get some alternative that can handle C++11.)
In my opinion, the more complicated your code becomes the more useful real debugging support is. You can save hours compared to using debug prints etc.
1 Like
I haven’t had time to do any more investigation myself but from what Jonne has said it sounds like getting PlatformIO to work has been a huge pain to get up and running. I don’t quite understand the reasons why the hardware debugging is behind a paywall. Do you need extra hardware to do the debugging on device or should it be possible via USB? Does it use gdb or something else?
At this point I’m wondering if it would be worth just making a simple Makefile to handle compilation, similar to how the Uzebox setup works. Potentially it could target both simulator and actual hardware, plus be suitable for cross platform development on Windows, Mac and Linux. It isn’t as friendly for beginners as something like the Arduino IDE but potentially could work with IDEs like Visual Studio etc.
Thoughts?
As much as I detest cmake and makefiles, I’d really like for there to be other options available for Mac and Linux (despite not using either), so it might be worth considering.
(And frankly Visual Studio is my favourite IDE, even if I preferred the 2010 UI to the modern ones.)
if prefer a makefile on mac/linux since thats alteast one les dependancy (make comes pre isntalled on both platfroms)
whats the exact pipeline we would have to folow for that?
Sorry, haven’t had any time to pursue this any further.
Hopefully at some point, because I’d really prefer a solution like PIO.
Until then it’s impossible for me to make anything for pokitto.
1 Like
Sadly not.
Yup. It means making a platformio.ini.
The makefile should serve as a good base for what settings need to be filled with what though.
It should at least give a clue as to what the compiler settings should be.
Otherwise it’s going to just be a matter of knucking down and fighting the documentation.
On the other hand, aparently Code::Blocks can use custom makefiles to build.
We’re already recommending Code::Blocks for the simulator, so maybe that would be a good stepping stone?
(Also EmBitz is a fork of Code::Blocks, so the UI is quite similar - shouldn’t be a major leap for those who are used to EmBitz.)
That was a fast reply.
I was thinking more about how far you had gotten.
If you had a half-built platformio.ini, that could possibly serve as a starting point.
Can’t get mbed online or EmBitz working?
Or just don’t want to use either?
While I’m thinking of library things.
I cannot deny how useful Arduboy2's justPressed is.
I find myself using Buttons::held in an attempt to simulate it, so a future buttons API would do well to accomodate both the current ‘timed’ functions and something more like justPressed.
Come to think of it, if the buttons are updated via interrupt, what metric/time interval is used for defining the timeHeld (and related functions)?
Is it the number of calls to update or pollButtons?
I’m sure as hell not going to develop anything with a webbrowser and EmBitz only works on windows.
PlatformIO seemed the most logical route for me to use the pokitto-libs with mbed for this target using a cli toolchain, but yeah no time to investigate.
I ran in to lots of dependency/path issues when trying to build the hello-world example. Maybe I can have another shot at it, but it’s probably best to start the effort from scratch (don’t have my files from then).
Same here. Platformio is a pain in the ass to set up
You mean the pokitto-libs are a pain in the ass to use with other toolchains? 
No. If you try to compile just the normal LPC11U68 target, it won’t work out of the box
1 Like
Hmm, indeed I can’t compile the mbed hello world example.
Submitted a bug-report about this to PIO.