u0_a256 has quit [Read error: Connection reset by peer]
u0_a256 has joined #openocd
u0_a256 has quit [Read error: Connection reset by peer]
matsievskiysv has quit [Quit: Quit]
Haohmaru has quit [Ping timeout: 260 seconds]
Hawk777 has joined #openocd
Haohmaru has joined #openocd
Haohmaru has quit [Client Quit]
merethan_ has quit [Quit: Leaving]
<gamiee>
Hi! Please, does anyone know how GDB instructs OpenOCD to write firmware to flash? When load is executed by gdb, it just writes it as memory. It does not use flash functions.
Guest44 has joined #openocd
Guest44 has left #openocd [#openocd]
oVexlz has joined #openocd
<oVexlz>
Is this chat active? Was curious about how OpenOCD interprets addresses out of symbol tables
<Hawk777>
Other than for the RTOS threading support, I thought it didn’t do anything with symbol tables at all. I thought that was all left to GDB.
<oVexlz>
I'd also be very open to general advice about GDB, its definitely possible the issue lies there. I'm using an STM8 in the large memory model configuration (has 96 KB of flash memory, uses fancy extended bit addressing to access the > 16 bit space), the exact issue I'm running into is that somewhere between me setting a breakpoint on a symbol in
<oVexlz>
that upper 32 KB region and the address getting parsed, its truncating that address down to 16 bits.
<oVexlz>
Have confirmed my ELF contains the valid, untruncated addresses, but a little lost on how to chase this down further
<Hawk777>
Unfortunately I can’t help you there. I've never used OpenOCD with <32-bit targets.
<Hawk777>
Maybe someone else knows.
<oVexlz>
Yep, I'll lurk around and hopefully someone might have some experience, pain of working with a pretty niche MPU
nerozero has quit [Ping timeout: 255 seconds]
<oVexlz>
Looks like GDB architecture is set to STM8, I'm wondering if that doesn't support >16 bit addressing
guestinator has joined #openocd
<PaulFertser>
gamiee: hi! "load" in GDB works differently depending on the memory map which OpenOCD passes it on connection.
<PaulFertser>
gamiee: if memory map declares some region as flash then gdb will first send a command to erase it and then another command to flash it. If not, it'll just try writing as if it's regular memory.
<PaulFertser>
oVexlz: indeed OpenOCD deals with symbols only for RTOS awareness and it counts on GDB to resolve the names to addresses.
<PaulFertser>
oVexlz: "set debug remote 1" in GDB prior to doing "continue" after setting a breakpoint and you'll see which address it asks OpenOCD for.
<oVexlz>
I'm definitely leaning towards this being a GDB issue where the architecture isn't correctly configured from ST to support the extended addressing mode. I'm using this version of GDB