<linuxdude>
how would I go about adding openocd support to s32k344 mcu?
linuxdude has quit [Remote host closed the connection]
linuxdude has joined #openocd
linuxdude has quit [Remote host closed the connection]
nerozero has joined #openocd
Hawk777 has joined #openocd
<antto>
with a bit more than 5 minutes of patience
Hawk777 has quit [Quit: Leaving.]
Haohmaru has joined #openocd
Haohmaru has quit [Read error: Connection reset by peer]
HelloShitty has joined #openocd
vampirefrog has joined #openocd
HelloShittyAlt has joined #openocd
HelloShitty has quit [Ping timeout: 258 seconds]
HelloShitty has joined #openocd
HelloShittyAlt has quit [Ping timeout: 258 seconds]
HelloShittyAlt has joined #openocd
HelloShitty has quit [Ping timeout: 258 seconds]
HelloShittyAlt is now known as HelloShitty
HelloShittyAlt has joined #openocd
HelloShitty has quit [Ping timeout: 240 seconds]
HelloShitty has joined #openocd
HelloShittyAlt has quit [Ping timeout: 245 seconds]
HelloShittyAlt has joined #openocd
HelloShitty has quit [Ping timeout: 258 seconds]
merethan has joined #openocd
HelloShitty has joined #openocd
HelloShittyAlt has quit [Ping timeout: 260 seconds]
HelloShittyAlt has joined #openocd
HelloShitty has quit [Ping timeout: 240 seconds]
HelloShitty has joined #openocd
HelloShittyAlt has quit [Ping timeout: 258 seconds]
<merethan>
<PaulFertser> merethan: probably wrong stack pointer past the RAM?
<merethan>
mm that might be PaulFertser. My CPU does stuff (it runs the Reset_Handler) up until it calls the first function. Which would be the first time pushing the stack?
<merethan>
__stack is at 0x2000800 so should be fine (I prefer my stack at the start of RAM) with __StackLimit being 0x20000000
<merethan>
I can't quite explain it. It is __libc_init_array() it hangs on. But it even hangs when I make the arrays __preinit_array_start, __preinit_array_end and __init_array_start, __init_array_end zero in size. Reading the newlib source, this only leaves _init() as potential culprit or the fact a function is called (stack is used) itself. But stack bounds seem to be set correct... Confusing.
<PaulFertser>
merethan: hey
<PaulFertser>
merethan: stack pointer usually should point to end of SRAM.
<PaulFertser>
merethan: early crash like you describe hints at writing something outside.
<PaulFertser>
merethan: after stopping on exception you can do "up" in gdb to get to the frame which caused the exception and then inspect "disasm" and "i r".
<PaulFertser>
merethan: there must be some specific assembly instruction that leads to hard fault.
<merethan>
Tnx for the hint! On it.
<merethan>
I was looping at the assembly of _init(), but that's just pushing & a NOP.
<merethan>
*looking
<PaulFertser>
merethan: you can do another trick "mon reset halt" and then "si" and press Enter till you hit the instruction that fails, then you can set a breakpoint there and do "run" to restart and stop at that moment.
<merethan>
I know stacks are usually at the end of ram PaulFertser, reason I like them being at the beginning is because a stack overrun then creates a HardFault rather than corrupting heap.
<merethan>
Also, I got two CPU's in my package now and they can't both have their stack at end of RAM :P
<PaulFertser>
merethan: btw, you should probably inspect registers right after "reset halt" to see if stack pointer register has the right value since you use custom linker script.
<merethan>
Think I did that but will do again
<merethan>
STM32WL55 here: Cortex-M4 & Cortex-M0+
<PaulFertser>
On Cortex-M the sp value is loaded from the very first word of the firmware, and reset vector from the second.
<merethan>
Yes.
<PaulFertser>
merethan: so disassembly at the point that fails and register contents at the same time should reveal the reason.
<merethan>
On it.
<merethan>
This would be a perfect moment to impersonate Samuel L. Jackson as he delivered his character in Pulp Fiction :P
<merethan>
Yeah I screwed up my stack definition.
<PaulFertser>
merethan: what was it?
<merethan>
So the assembly startup code uses the symbol _estack for setting the stack pointer. Which I assumed to be synonymous to end of stack. A stack being something which grows down, not up, the end would be the lower boundary. But apparently the symbol _estack is taken as the end of it, going forward in RAM.
<PaulFertser>
Ah, that would explain it :)
<merethan>
So, I need set _estack not to what is now equivalent to __StackLimit but to __StackTop
<merethan>
Meaning it was not the functions or instructions therein that caused me a HardFault, but the fact I entered a function itself, because that causes the stack to be pushed.
<PaulFertser>
Makes sense.
<PaulFertser>
Usually bss cleaning is done before entering any functions iirc?
<PaulFertser>
Hm, but that should be safe, not related to stack pointer, ok.
<PaulFertser>
Great to have OCD to see that all right away.
<merethan>
Yes. OpenOCD makes me feel like a god :P
HelloShittyAlt has joined #openocd
HelloShittyAlt has quit [Client Quit]
HelloShitty has quit [Ping timeout: 258 seconds]
<merethan>
I fixed my stack but newlib init keeps failing :(
<merethan>
I disabled some code and got to my main() and everything, which works for a good bit (to my surprise).
bvernoux has joined #openocd
<merethan>
So my stack machine works. I can even write flash, configure peripherals and some stuff. But newlib fails on init.
<karlp>
what is "newlib init" ?
<merethan>
As soon as the Reset_Handler goes into __libc_init_array() CPU goes HardFart
dliviu has quit [Quit: Going away]
<merethan>
I got newlib from my Linux distro in binary form on disk, perhaps architecture mismatch?
dliviu has joined #openocd
<PaulFertser>
merethan: unlikely, distros package newlib in multilib way, so if you have a set of options matching one of "arm-none-eabi-gcc -print-multi-lib" it should be right.
<PaulFertser>
merethan: either way, look at the disassembly and registers to see why exactly it fails.
<karlp>
who wrote your linker script?
<karlp>
did you get it from the same place as your "newlib" ?
<merethan>
I did myself.
Hawk777 has joined #openocd
<karlp>
and it matches the expectations and required variables of whatever startup code you're using right?
<merethan>
To my best understanding yes.
<merethan>
Essentially what it does in __libc_init_array() is take all pointers between __preinit_array_start, __preinit_array_end & __init_array_start, __init_array_end and executes them.
<merethan>
But even when I set *_start & *_end the same (meaning no list and thus no for loops will be run) it still makes a HardFault situation.
<merethan>
I've been stepping through it and viewing the disassembly and doing info registers on it, but nothing out of the ordinary to my eyes yet.
<karlp>
I'm 99% sure you're not using that code :) as a reference it might be nice but you really want to look at your buildroot to see what you're really using...
<merethan>
Yes I downloaded the source from Debian. It's by about the same; some formatting differences.
<merethan>
And by some I mean three.
<merethan>
I must be overlooking something. It really makes no sense to me: When I make those for-loops not execute by having starts & ends identical it still hangs my CPU. And the _init() function comprises of a NOP in my disassembly.
<Hawk777>
A NOP plus a RET hopefully?
<merethan>
Does objdump -d show those? Because I not see RET on any function.
<merethan>
When I read disassembly for _init() it does push, NOP, but not pop.
<Hawk777>
objdump should show the RETs.
<merethan>
By RET you mean pop right?
<Hawk777>
Maybe? What CPU architecture is this? Some of them can do a function return just with a POP, others would need a separate RET instruction or something similar.
<merethan>
Cortex-M4
<Hawk777>
x86 can’t do it with POP and must use RET I believe. ARM can do it with BX LR if LR is not saved on the stack, otherwise if the stack layout is right, it could do it with a POP that includes PC as a target in the position where LR was saved.
<merethan>
Hawk777, am I understanding your suggestion right that the absence of setting the PC back to the calling function may be the cause for my trouble?
<Hawk777>
Yeah, the CPU doesn’t magically know where the end of the function is. If there isn’t an instruction that returns, it doesn’t return, it just carries on running whatever bytes show up after the function body.
<merethan>
Mm I'll try to override _init() with my own implementation (of it being just a return)
<Hawk777>
If you were single-stepping, you should have seen where it went wrong? Did it enter _init and then not come back? Did it step to past the end of _init?
<merethan>
When I did stepping using OCD it just enters the function and next step CPU is HardFaulted.
<merethan>
Maybe the function is inlined. Would the symbol still be in the .elf if it was?
<Hawk777>
Not sure, I would think not. By “the function” do you mean _init or a different function?
<merethan>
I did objdump -d | less then searched for _init
<Hawk777>
What I mean is, which function does it enter?
<Hawk777>
Does it enter _init, or does it crash entering __libc_init_array and not get to _init at all?
<merethan>
But I'm not compiling __libc_init_array(), it is provided by Debian as part of the newlib package in binary form.
<Hawk777>
Either way, another possible problem I can think of is that one or the other function (or both) is trying to use the stack at some point, and the stack doesn’t work right yet (either SP is pointing at the wrong place, or SP is pointing at a reasonable address but it points at RAM that hasn’t been powered up yet, or clocked, or whatever).
<merethan>
That's a very good suggestion actually.
<merethan>
Thing is, the stack does work if I just skip __libc_init_array()
<merethan>
So for as far memory & SP go, I think I'm good there.
<Hawk777>
ah, well, probably not that then
<Hawk777>
Would you be able to share localized snippets of the disassembly of _init, and ideally also __libc_init_array?
<Hawk777>
OK, yeah, that _init and _fini both look problematic, they’re going to push a bunch of registers, do nothing, and then fall off the end.
<merethan>
Strange eh?
<Hawk777>
Where is _init defined in source?
<merethan_>
I believe it's in src/newlib-3.3.0/libgloss/arm/crt0.S
<merethan>
So it is not assembly generated by a compiler.
<Hawk777>
Hm, that doesn’t look like it’s defininig it, it looks more like it’s maybe calling it? A bit hard to read.
<Hawk777>
I suspect what might be happening is that _init is supposed to comprise a push generated by one entity (maybe the stdlib or maybe the compiler), follows by a bunch of calls to functions inserted by the linker, and either the last one is a jump instead of a call or the linker adds a return after the last one. But the linker has not been told to do that, so you just have the “basic” definition which is missing the linker-provided piec
<Hawk777>
e and therefore doesn’t work.
<merethan_>
The function is defined in /usr/lib/gcc/arm-none-eabi/12.2.1/thumb/v7e-m/nofp/crti.o for me.
<merethan_>
Content is the same in that file as the pastebin.
<merethan>
Did I not read the manual correctly? Because if what you write is true, there must be docs on it somewhere I guess?
<Hawk777>
Right, what I’m saying is it’s possible the linker is supposed to insert additional code into the function during linking, as it collects the constructor symbols from the various things going into the link.
<PaulFertser>
__libc_init_array is used for static objects constructors in C++ and similar things
<Hawk777>
__attribute__((constructor)) does something along these lines. I think on some platforms the init-array stuff is used (which is an array of function pointers to pre-main code to run), and on other platforms the linker assembles the pieces into a sequence of code in _init (i.e. a sequence of instructions rather than an array of function pointers0.
<PaulFertser>
Probably you should just try non-hacked linker script ?
<merethan>
Well if that were a problem PaulFertser I'd rather discover what my error is.
<merethan>
I'm also not exactly new to linker scripts so if the stock one would do it, there's a specific thing about it.
<PaulFertser>
merethan: of course it's better to understand the reason. Having a working data point is good for that.
<merethan>
I'd like to note with that, that most linker scripts are a gobble of generated code treated as some esoteric piece of knowledge noone dares to touch. That includes the one STM gave me for my WL55 chip.
<merethan>
There's a lot of irrelevant (desktop-only) stuff in it, and far from lets say optimal.
<PaulFertser>
merethan: libopencm3 has its own scripts
<merethan_>
Also Hawk777, in case it tickles your interests to see my linker script.
<PaulFertser>
merethan_: did you paste the register state output at the moment it fails?
<Hawk777>
To quote https://www.man7.org/linux/man-pages/man5/elf.5.html : “[The .init]section holds executable instructions that contribute to the process initialization code.” Your linker script is just dumping *(.init) in a random place in .text. I suspect the contents of those input sections are supposed to be concatenated immediately after the _init function snippet from crti.o, and then somehow a return added at the end.
<merethan>
Today I practiced my Halloween outfit going to work.
<merethan>
Totally off-topic but guessed it be fun.
<merethan>
I guess The Matrix movies need no explanation.
<Hawk777>
At least among programmer circles I suppose.
<PaulFertser>
:D
<merethan>
I'll be picking up the girlfriend like this in an hour or so. Will probably surprise her quite a bit :P
<PaulFertser>
Did you get a haircut for the occassion?
<merethan>
No already had that.
<PaulFertser>
Probably it's hard to surprise anyone with a costume in your part of the world this day. You'd surprise me, I had no idea halloween is coming :)
<merethan>
Oh I surprised everyone here at work. I normally walk around in tank tops & hoodies.
<PaulFertser>
:D
<merethan>
Some were inspired to also get an act going. Colleague of mine already had plans for being The Architect.
<merethan>
(Also from the movie.)
<PaulFertser>
I've read that the original idea was that the machines were using humans as a distributed neural network to process data they needed. That makes so much more sense than "batteries".
<merethan>
Yeah, quite so.
<merethan>
Think they refrained from that, because that's kinda the plot of that other 1999 movie.