sbach has quit [Read error: Connection reset by peer]
sbach has joined #openocd
thinkfat has joined #openocd
thinkfat_ has quit [Ping timeout: 264 seconds]
Hawk777 has joined #openocd
nerozero has joined #openocd
erhankur has quit [Remote host closed the connection]
erhankur has joined #openocd
Haohmaru has joined #openocd
zkrx has quit [Read error: Connection reset by peer]
zkrx has joined #openocd
erhankur has quit [Remote host closed the connection]
erhankur has joined #openocd
erhankur has quit [Remote host closed the connection]
erhankur has joined #openocd
c4017 has quit [Quit: Client closed]
Hawk777 has quit [Quit: Leaving.]
wingsorc has quit [Remote host closed the connection]
wingsorc has joined #openocd
zkrx has quit [Read error: Connection reset by peer]
zkrx has joined #openocd
<bobsy>
PaulFertser, thanks.
<PaulFertser>
bobsy: hope you manage to recover the board
<bobsy>
PaulFertser, thanks
<bobsy>
PaulFertser, i erased it to the point there is no uboot :(
<bobsy>
what is this so-called calibration data?
<bobsy>
i have a dialog open with the manufacturer, if i need it i can ask for it..?
<PaulFertser>
bobsy: u-boot is usually at the beginning of the flash. Calibration data is in some other area. I do not think the manufacturer keeps backups for calibration data, they're likely measured and flashed on the factory and that's it.
<bobsy>
well they offered for me to return the board to china and they would rewrite the chip
<PaulFertser>
bobsy: you need to read the DTS file for your board to see where calibration data is exactly. What exactly did you do to erase u-boot?
<bobsy>
so i'll see what they say when i say i got this to write to it
<bobsy>
PaulFertser, the erase command at the uboot interface
<PaulFertser>
bobsy: with what arguments exactly?
<bobsy>
god knows, i don't remember..
<PaulFertser>
bobsy: in any case take full backup of the existing contents several times after you receive the clamp.
<bobsy>
i have a derivittve of the same board here that still works
<bobsy>
can i just read from that
<bobsy>
infact i have another one of the exact same board (however i gave it to a friend 2 hours drive away)
<bobsy>
PaulFertser, ok
wingsorc has quit [Ping timeout: 268 seconds]
<bobsy>
like, i should be able to read from the good board then just overwrite the bricked one, yea?
<PaulFertser>
bobsy: using calibration from one board on another might make it perform outside the specs, you're not legally allowed to do that.
<bobsy>
even if it's the exact same model?
<PaulFertser>
Yes, unless you are 100 % sure all of them got identical calibration data or you do not care about breaking the RF regulations.
<PaulFertser>
If there're other wifi or bluetooth devices around which do not belong to you, using wrong calibration might create extra interference for them.
<bobsy>
oops my connection just dropped, i may have missed your answer if you gave one.
<PaulFertser>
Yes, unless you are 100 % sure all of them got identical calibration data or you do not care about breaking the RF regulations.
<PaulFertser>
If there're other wifi or bluetooth devices around which do not belong to you, using wrong calibration might create extra interference for them.
<PaulFertser>
You can search the OpenWrt forum to see what the others say about lost calibration cases.
<bobsy>
cool
<bobsy>
thanks PaulFertser
indy has quit [Ping timeout: 265 seconds]
<PaulFertser>
bobsy: ask the board vendor if unsure
<bobsy>
PaulFertser, yeah i will, most certainly
erhankur has quit [Remote host closed the connection]
erhankur has joined #openocd
indy has joined #openocd
erhankur has quit [Remote host closed the connection]
uartist has quit [Read error: Connection reset by peer]
uartist has joined #openocd
uartist has quit [Client Quit]
<braunr>
hmpf, that's trange
<braunr>
openocd can't find pxReadyTasksLists through gdb, but if i do it manually, the symbol is found
<braunr>
any idea about what could cause that ?
<braunr>
(it's a very recent git version)
<PaulFertser>
Probably elf file not loaded at the moment OpenOCD tries?
<braunr>
i don't see why not
<braunr>
i'm passing the elf as an argument to gdb, and connecting remotely to openocd
<braunr>
my configuration doesn't have anything special
<braunr>
just gdb attach/detach handlers
<braunr>
that just halt/resume
<karlp>
what do you mean by "if i do it manually" ?
<braunr>
p pxReadyTasksLists (once connected to openocd)
<karlp>
so... what _doesn't_ work?
<braunr>
info threads, because openocd couldn't see that symbol
<karlp>
info threads only works if the rtos was detected, and the rtos detection is suuper wonky...
<karlp>
which version of (looks like freertos) is that?
<braunr>
freertos 10.1
<karlp>
there have also been changes in freertos to make it behave better in places like that.
<braunr>
yes i've worked on that a bit in the past
<braunr>
but usually, when i would get that error, gdb could really not find it
<braunr>
so how is it that openocd, through gdb, cannto find the symbol, but gdb on its own can ?
<braunr>
the elf file must provide that information somehow
* karlp
shrugs
<karlp>
one thing is that... are you doing a "load" here as well?
<braunr>
oh i know
<karlp>
because openocd often tries to read things when gdb asks it, based on symbols
<braunr>
LTOs :)
<karlp>
but it hasn't been flashed to that place yet..
<braunr>
they caused the symbol to be renamed, in a way that gdb can know but not openocd
<karlp>
hrm, I doubt that really.
<braunr>
yep, it works fine in debug mode
<braunr>
20014e3c 00000078 b pxReadyTasksLists
<braunr>
200155d8 00000078 B pxReadyTasksLists.lto_priv.0
<braunr>
(debug vs release)
<PaulFertser>
I thought about LTO but since I didn't try debugging LTO binaries much I've forgotten that GDB automatically resolves those *.lto_priv names.
<braunr>
it makes sense though, relying on a private (static) symbol as part of a "public" interface isn't reliable
<braunr>
mhm, i removed the static keyword for all symbols the freertos port needs, and it works fine