boru has quit [Killed (NickServ (GHOST command used by boru`))]
boru` is now known as boru
The_Jag_ has quit [Read error: Connection reset by peer]
The_Jag has joined #openocd
tsal has quit [Ping timeout: 260 seconds]
tsal has joined #openocd
The_Jag_ has joined #openocd
The_Jag has quit [Ping timeout: 264 seconds]
Hawk777 has joined #openocd
Bertl_oO is now known as Bertl_zZ
nerozero has joined #openocd
nerozero has quit [Remote host closed the connection]
Hawk777 has quit [Quit: Leaving.]
zkrx has quit [Killed (NickServ (GHOST command used by zkrx_))]
zkrx has joined #openocd
Jybz[m] has quit [Ping timeout: 260 seconds]
Jybz[m] has joined #openocd
Haohmaru has joined #openocd
urja has quit [Read error: Connection reset by peer]
urja has joined #openocd
jancoow has joined #openocd
<jancoow>
Hi. Sometimes when restarting openOCD I get an error Error: CMSIS-DAP command CMD_INFO failed. I've to re-plug my atmel ice in order to get it working again
<jancoow>
why is this
<PaulFertser>
jancoow: probably a bug in atmel ice firmware?
<jancoow>
not really sure, it only happens when I run openOCD from my run and debug in vscode
<jancoow>
maybe it does not exit openocd gracefully
<Haohmaru>
yeah, the firmware gets updated from time to time, which means.. it's not absolutely great to begin with
<Haohmaru>
mine got auto-updated immediately when i had AtmelStudio running and it saw me plug the brand-new atmel-ice
<jancoow>
I'm trying to move on from my windows VM with atmel studio to vscode
<jancoow>
because im getting so.tired.of.atmel.studio
<Haohmaru>
AtmelStudio sux
<Haohmaru>
because it's some uber heavy crap based on M$VS or whatever
<jancoow>
ye, it only takes 10 minutes to start up, and if I include a sub-project a step-over or breakpoint hit takes 1 minute
<PaulFertser>
Yeah, probably the firmware needs CMD_DAP_DISCONNECT to reliably reply to info requests.
<PaulFertser>
jancoow: you can try adding a static int cmsis_dap_cmd_dap_disconnect(void)
<PaulFertser>
call to init
<jancoow>
compile times, even with my own cmake and ninja, are insane long. I think it's 5 times so fast on linux lol
<jancoow>
PaulFertser huh?
<jancoow>
how exactly?
<Haohmaru>
PaulFertser wouldn't that affect the other DAP-based debuggers tho?
<PaulFertser>
jancoow: I'm reading the cmsis-dap driver source.
<Haohmaru>
i don't think i've seen such a glitch with openocd+zl33prog
<PaulFertser>
Haohmaru: should be a no-op if not connected alredy.
<jancoow>
i've to say if I ctrl+c it normally from my own console I don't see any issues
<jancoow>
I think it only happens when vscode exit openocd
<PaulFertser>
jancoow: what if you kill with sigterm?
<PaulFertser>
jancoow: what OpenOCD version?
<jancoow>
lemme check
<jancoow>
0.11.0
<PaulFertser>
jancoow: the issue you report might have been fixed with v0.11.0-103-gff755a575
<PaulFertser>
jancoow: I suggest you try current master.
<jancoow>
with debugging trace, i see Error: CMSIS-DAP transfer count mismatch: expected 1, got 0
<jancoow>
I think indeed this happens after a sigint
<jancoow>
for some reason vscode send that..
<Haohmaru>
you run openocd thru the IDE?
<jancoow>
yes, otherwise pause does not work through gdb
<jancoow>
for some reason
<Haohmaru>
hm, my setup is different
<PaulFertser>
jancoow: try current master, many changes happened to cmsis-dap driver since 0.11.0
<jancoow>
but if I set it in "debugServerPath" its okay
<jancoow>
PaulFertser i'll check!
<Haohmaru>
i run openocd manually from a terminal, my IDE only runs gdb
<jancoow>
yes that is what I wanted to do too but then I'm unable to pause the target
<jancoow>
(for some reason..)
<Haohmaru>
huh, pause.. works in my setup
<jancoow>
do you use vscode?
<Haohmaru>
hell no
<Haohmaru>
Code::Blocks
<jancoow>
never herad of
<Haohmaru>
it's an old, very configurable and very resource-conservative IDE
<Haohmaru>
and cross-platform
<Haohmaru>
isn't vscode one of those that basically run a whole webbrowser for the GUI?
<jancoow>
vscode is cool tbh
<jancoow>
it got all the thing I need
<jancoow>
the only thing is a button to reset my target
<Haohmaru>
wikipedia says "TypeScript, JavaScript, HTML, and CSS"
<jancoow>
i miss is (
<Haohmaru>
well, f*ck that ^
<jancoow>
*
<jancoow>
haha that's wrong
<jancoow>
got support for basically everything
<Haohmaru>
i meant "written in"
<jancoow>
yes, welcome to 2021 ;p
<Haohmaru>
"It is based on the Electron framework"
<jancoow>
you can't judge a tool based on the language it is written in tbh
<PaulFertser>
Even if it's PHP? ;)
<jancoow>
there are limits
<Haohmaru>
well it reached my limit
<jancoow>
well everyone it's thing right?
<Haohmaru>
that sh*t would eat like 500MB RAM before it can even begin to do anything semi-useful
<jancoow>
the windows virtual machine i need to run for atmel studio eats 6gb of ream
<jancoow>
ram
<jancoow>
so this is an improvement for me already
<PaulFertser>
jancoow: have you considered QtCreator?
<jancoow>
PaulFertser that is for qt designers?
<Haohmaru>
i already said i ain't running no AtmelStudio, that sh*t is crap too
<PaulFertser>
jancoow: no, it can be used as a general-purpose IDE and it has support for bare metal debug.
<Haohmaru>
i don't care if it eats 500MB or 2GB.. it's a fancy text editor, it should be over 50MB or RAM when you have nothing opened in it yet
<jancoow>
PaulFertser I've got a run configuration which does indeed start gdb
<PaulFertser>
jancoow: "start" command in GDB means "place temporary breakpoint on main() and restart the target"
<jancoow>
well, it's rather slow to restart gdb and openocd
<jancoow>
slower then sending a reset
<PaulFertser>
jancoow: I'm not talking about restarting any host processes.
<bencoh>
can the start command trigger user-defined hooks in gdb?
<bencoh>
(like sending custom monitor commands)
<bencoh>
I usually end up writing my own user-defined reset command when I need to debug some mcu with gdb and reset/reflash it
<jancoow>
PaulFertser what do you exactly mean?
<PaulFertser>
Usually I can reflash with "load" and then just "continue"
<PaulFertser>
jancoow: I mean GDB commands
<jancoow>
PaulFertser oh uhm
<jancoow>
PaulFertser that would re-open a new gdb connection and send one command?
<PaulFertser>
jancoow: no, I mean a command that one sends _to_ GDB (e.g. via its interactive cli)
<bencoh>
lucky you, I need to monitor reset/halt, set a few registers, and call the reset_handler manually
<bencoh>
otherwise gdb doesn't "resync" properly
<jancoow>
PaulFertser thanks mate, version 0.11.0+dev-00418-g918811529 works
<jancoow>
PaulFertser im not sure how to do that in vscode :(
<PaulFertser>
jancoow: I know in Eclipse you can just type GDB commands in some pane.
<jancoow>
PaulFertser I can type them, that's not the problem, I would just wish I could add a button ;p
<jancoow>
i'm sure this is possible somewhere
<PaulFertser>
bencoh: with load by default OpenOCD first runs "reset init", then the flashing process happens, then "reset halt". So that last reset halt should do everything necessary, the same way the target normally runs after power-on-reset.
<PaulFertser>
bencoh: for resync there's another OpenOCD command: mon gdb_sync and then you do "si" for the actual sync.
<bencoh>
I don't think openocd is at fault here tbh ... oh, I'll have to check gdb_sync
<bencoh>
I'll have to check gdb's start as well someday :)
<PaulFertser>
For "start" and "run" to work one needs to use target extended-remote (not just remote).
<bencoh>
oh, might be related
<bencoh>
I'm pretty certain I still use remote out of habit
<PaulFertser>
"tar ext :3333"
<bencoh>
hmm, this might also explain why I didn't get hwthread working properly yesterday (on a completely different target)
<PaulFertser>
Not sure if it can be related, I'd say unlikely.
<bencoh>
ah
<bencoh>
well
<GyrosGeier>
one thing I'd need at some point would be a server mode that doesn't rely on a shared file system
<GyrosGeier>
e.g. transferring an SVF file through the server connection instead of creating a tempfile and passing its name
<GyrosGeier>
that is rather difficult to do on Docker
<Haohmaru>
svf?
<GyrosGeier>
Serial Vector Format
<PaulFertser>
GyrosGeier: hm, why is getting a file to a *nix system difficult?
<GyrosGeier>
I have a toolchain that compiles an FPGA image with the Altera compiler, then converts it to SVF, which is basically JTAG instructions
<GyrosGeier>
that runs in a Gitlab runner
<PaulFertser>
GyrosGeier: you have manual "irscan" and "drscan" commands but that's not exactly svf player.
<karlp>
PaulFertser: same issue is for using opencd remotely without gdb...
<PaulFertser>
So why can't the file be scp'd to the host running OpenOCD?
<GyrosGeier>
that host is a container that isn't exposed to the net
<PaulFertser>
karlp: well, yes, but why?
<karlp>
why should it have to be separately managed? that's a hassle
<karlp>
maybe it doesn't have a writeable disk,
<GyrosGeier>
basically, I use Gitlab for FPGAs
<karlp>
it's just a thing that makes it awkward to use remotely.
<PaulFertser>
tmpfs is there when you need it.
<karlp>
despite being a "client server" remote application
<PaulFertser>
karlp: how about using Tcl to write that file to /tmp?
<GyrosGeier>
there are build machines, and test machines
<karlp>
PaulFertser: sure, could probably be done with insane tcl, but that's insane tcl :)
<GyrosGeier>
and the test machines are really just containers on a server that have an USB device forwarded into them
<karlp>
just poitning out that this is not unreasonable, and GyrosGeier is _farrrr_ from the first person to want such functionality standard :)
<PaulFertser>
karlp: it's unclear what sane architecture can one imagine so that OpenOCD would be getting e.g. ELFs via network on its own.
<jancoow>
is it possible to increase the clcok speed on the atmel ice? I can only program at 400khz
<Haohmaru>
hm, i thought it goes slightly faster than that
<jancoow>
it says Info : clock speed 400 kHz
<Haohmaru>
or is that a clock on the SWD side of things?
<GyrosGeier>
PaulFertser, writing an ELF to a target is not an uncommon task, I think
<karlp>
PaulFertser: are you not hearing that it's just a pain in the neck? sure, it's all _feasible_ but it's a lot more singing and dancing than it feels like it should be when it's already a "remote server" application
<Haohmaru>
i mean the clock which is part of the SWD interface, not some clock on the USB side of things
<jancoow>
uhm?
<Haohmaru>
yeah i guess that
<bencoh>
400kHz is probably swd clock yeah
<PaulFertser>
karlp: I am hearing. I can't fully grasp why the file can't be simply scp'd or fuse-mounted with sshfs etc.
<karlp>
because it's all a pile of extra steps that need ot be hand scripted and automated by every person all the time
<jancoow>
can't it go faster?
<GyrosGeier>
it's a separate connection
<jancoow>
it says on startup Info : clock speed 400 kHz
<karlp>
docker makes it even more complicated of course.
<GyrosGeier>
that needs to be authenticated, so you need to roll out a mechanism for that
<Haohmaru>
no idea what mine at home was, but iirc the "speed" of debugging was more limited by something on the USB side of things with the older DAP-based debuggers
<PaulFertser>
karlp: ok, let's say I understand there's a problem but I can't imagine a true Unix way to solve it.
<karlp>
I'm not at all saying it can't be done, it's clearly what us remote people are aleady doing.
<Haohmaru>
newer ones had a way that this could be faster, it had to do with "bulk-transfer" or something like that
<GyrosGeier>
PaulFertser, a "here document" in the command stream?
<karlp>
let's just say that sometimes "the unix way" sucks monkey balls as it requires every single end user to put their own string together between all the parts...
<bencoh>
Haohmaru: are you certain it was usb, or not some parport? :)
<GyrosGeier>
I mean, even SCPI does that :>
<jancoow>
it takes 20 seconds to flash: wrote 215400 bytes from file test.hex in 21.110640s (9.964 KiB/s)
<Haohmaru>
bencoh i have a zl33prog debugger, which is DAP-based, it's USB
<jancoow>
im not sure if that is normal
<karlp>
I mean, why on earth does openocd provide both the telnet _and_ the tcl interface _and_ the gdb interface? surely those should be separte tools assembled together by the user too?
<Haohmaru>
i also have an atmel-ice, the "speed" of it feels the same
<karlp>
Haohmaru: you maybe hearing/remmebering cmsis-dap v1 vs cmsis-dap v2, which is usb-hid vs usb bulk.
<Haohmaru>
yeah that sort of thing
<PaulFertser>
GyrosGeier: I think you can just wrap all SVF in {} and write to /tmp with Tcl, yes.
<Haohmaru>
that was one thing that limits the ultimate speed of things
<bencoh>
ah, I see :)
<Haohmaru>
particularly flashing the firmware before debugging
<jancoow>
adapter speed doesn't do anything
<PaulFertser>
jancoow: how do you flash, with what commands?
<PaulFertser>
jancoow: reset init calls the init handler and many targets setup PLL and ramp up the speed in there.
<PaulFertser>
jancoow: btw, why not "program" (openocd command) which automates all the steps?
<jancoow>
lemme check
<jancoow>
i didnt know about that command
<jancoow>
that command does not tell me how long it took ;p
<Haohmaru>
i should upgrade my debian to 11, there's openocd 0.11.0 in it
<PaulFertser>
jancoow: it runs write_image under the hood so should output something too.
<PaulFertser>
jancoow: the init handler is in the target config.
<jancoow>
** Programming Started ** \n Info : SAMD MCU: SAML21G18B (256KB Flash, 32KB RAM) \n ** Programming Finished **
<Haohmaru>
are those \n really there?
<jancoow>
no
<Haohmaru>
ah, k
<jancoow>
I just didn't want to paste 3 lines here
<PaulFertser>
jancoow: I see, so something to improve in "program" then. The way messages are output was changed after "program" was implemented.
<jancoow>
ah okay
<jancoow>
when I time it it still takes 20s
<PaulFertser>
jancoow: sure, it's the same command under the hood. Just allows you to also verify and reset the target to let it run right away.
<Haohmaru>
so if the SWD clock speed is 400kHz then at best the flashing transfere can't be any faster than 50kB/sec i guess
<PaulFertser>
You can try ramping up the speed by editing the target config file.
<Haohmaru>
no matter if the USB is bulk/overclocked/turbo-diesel
<jancoow>
I've to ask my collegue but I think he can flash it in 10 seconds with pyocd
<jancoow>
haha Haohmaru
<jancoow>
PaulFertser how
<GyrosGeier>
at a company I used to work we built an FPGA based JTAG adapter for ARM
<Haohmaru>
how fancy
<GyrosGeier>
50 MHz JTAG clock, managed about 4 MB/s
<PaulFertser>
jancoow: by literally using a text editor on the target config you're sourcing.
<Haohmaru>
wowz
<jancoow>
GyrosGeier dang
<Haohmaru>
my chip iirc has max 2MB flash
<PaulFertser>
GyrosGeier: for the reference, cheap FT232H manages 30 MHz JTAG clock.
<jancoow>
PaulFertser ah !
<jancoow>
PaulFertser I didn't know it was in the target config file
<GyrosGeier>
the FPGA was mostly used for the conditional waits
<karlp>
Haohmaru: wrt v1 vs v2, v1 was still fast enoughf ro most people, v2 was jsut required when they wanted to get trace in, and use usb-hs.
<GyrosGeier>
and in several places we just assumed pipeline state based on what we knew about the architecture
<jancoow>
not sure where the target files are under linux
<GyrosGeier>
if we can read back correctly, then obviously the transfer must have worked
<jancoow>
/usr/share/openocd
<jancoow>
i see
<PaulFertser>
jancoow: I suggest you make a copy of the target file and play with it first.
<Haohmaru>
karlp i wasn't thinking about the 400kHz SWD clock aspect tho, i don't remember whether mine was 400kHz but that sounds very slow
<Haohmaru>
i got 1MHz USART with my bootloader when flashing the silly xmega firmware
<Haohmaru>
so that would give an absolute max of.. 100kB/sec
<Haohmaru>
the xmega flash probably can't be written that fast tho, so it doesn't matter
<jancoow>
ah, steting it to 2mhz I can flash it in 10seconds, 20kb/s
<Haohmaru>
nice
<jancoow>
but how fast can it go
<jancoow>
4mhz only makes it .5 seconds slower
<jancoow>
(can you break it with a to high clock?)
<Haohmaru>
i had the impression that my setup at home was 2MHz too, i'll check when i get home
<Haohmaru>
well, when you go faster, the things that can break are usually clock edges getting lowpass'ed due to capacitance.. reflections..
<Haohmaru>
also, bidirectional signals (iirc SWD data was bidirectional) can go wrong and needs to be watched
<Haohmaru>
long cables are another problem
<Haohmaru>
or i mean, long electrical path (doesn't matter whether via cable or PCB tracks or what)
<Haohmaru>
and of course there's the actual MCU or device.. can it go that fast
<jancoow>
im not sure about that ye
<jancoow>
I don't see any improvement above 2mhz acutally
<jancoow>
i think atmel ice is capped n that
<Haohmaru>
on xmega/avr the flash is sliced into "pages" and each page is written separately, so one page at a time, and the flash peripheral thing requires you to wait for the page write operation to complete before you can go to the next one
<Haohmaru>
or, i think the erasing procedure was actually the slow bit
<jancoow>
yes im not erasing due bootloader and config stuff
<jancoow>
anyway thanks guys! you helped me so mcuh
<Haohmaru>
i mean you have to erase the page before writing it
<Haohmaru>
eeprom worked like that, writing a 0 bit is "easy", restoring that bit to 1 takes effort
<jancoow>
ah :)
<jancoow>
well 9.5 seconds is not bad
<Haohmaru>
yeah
<jancoow>
now one last thing... setting fuses
<Haohmaru>
how big is the binary tho?
<jancoow>
215400 bytes
<Haohmaru>
are there fuses?
<jancoow>
yes
<Haohmaru>
i don't remember fuses on the SAMD5x stuff for example
<Haohmaru>
huh
<jancoow>
we are using saml21 / samr34
<Haohmaru>
oh, those are maybe some of the new-ish ones
<Haohmaru>
is that M33 or some such?
<Haohmaru>
cortex-M33
<jancoow>
samr34/35 is kinda new ye
<jancoow>
but is just a saml21 + semtech sx
<Haohmaru>
oh, it has this LoRa thing
<Haohmaru>
and it's M0+
sbach has quit [Read error: Connection reset by peer]
<Haohmaru>
as for fuses, on xmega they can be defined in the code (gcc and/or the linker script has to be able to put them in the right place), then they are part of the .elf
<Haohmaru>
and then avrdude can either flash the elf (including fuses), or you could make individual .hex files out of that elf
sbach has joined #openocd
<Haohmaru>
jancoow if you got any example codez from microsh*t check how they deal with the fuses
<jancoow>
huwh
<jancoow>
normally I set fuses with atmel studio
<Haohmaru>
find out what it's actually doing then
<Haohmaru>
this is why i wanna write a lil document.. how to get an auto-generated project from atmel.start, and how to make it usable in Code::Blocks with gcc/gdb/openocd
<Haohmaru>
basically, it involves reading thru the autogenerated makefiles and/or AtmelStudio project file and figuring out the important things (compiler/linker flags, etc)
<jancoow>
well we have a custom linker script for our framework, not really using those autogenerated mess ;p
<jancoow>
so match our linker script i've to set eeprom size to 0x2
<jancoow>
and disable bootprot
<jancoow>
so set bootprot at 0x7
<Haohmaru>
yeah i mean, look thru the autogenerated crap to see where it stores the fuses
<jancoow>
it's not in the code
<Haohmaru>
maybe it would be in the IDE project file (that'd be unfortunate), but maybe it generates a fuses.c file
<Haohmaru>
aww
<jancoow>
no, you can set them without flashing an image or something?
Bertl_zZ is now known as Bertl
<Haohmaru>
jancoow avrdude in particular demands you tell it which "memory" you wanna program, and the program memory is separated from the fuse memory there (probably because the addresses), thus you need sepparate instructions to program the program memory, the eeprom, and the fuses, but they can be done with a single invokation of avrdude, and in each you can either put the .elf file or individual
<Haohmaru>
.hex files
<Haohmaru>
not sure about your case tho
<Haohmaru>
but i'd think the fuse memory will be part of the flash, probably at some particular address
<jancoow>
okay; i dont follow why you are refering to avr dude
<jancoow>
that is only used for arduinos and stuff right
<jancoow>
old avr mcus
<Haohmaru>
because i've dealt with fuses on avr mostly
<jancoow>
i think those are hardware fuses
<Haohmaru>
uhm, no, avr is general purpose 8bit (ignoring avr32 here)
<Haohmaru>
crapduino can go to hell
<jancoow>
arduino is great
<Haohmaru>
false ;P~
<jancoow>
for quickly hacking something together it does it job perfectly
<Haohmaru>
hm, i guess the SAME5x has fuses too but just i haven't fiddled with them yet
<Haohmaru>
well, this is the address: 0x00804000
<Haohmaru>
i'd think it should work similarly to how it works on xmega
<Haohmaru>
you'd wanna get the linker to put particular data values into the right address, and that has to make it into the .elf, then you'd want the programmer/debugger to pick it up from there and splosh it into the right place
<Haohmaru>
nah but i think the goal here was to unlock a locked bootloader
<jancoow>
ah ye
<Haohmaru>
* boot SECTOR
<jancoow>
ye that would be handy sometimes
<jancoow>
we lock this too with our automated tool
<Haohmaru>
speaking of which, you could check an existing project (like a bootloader for your chip or a similar chip) which *requires* some fuse to be changed from the default value, and see how they do it and their programming instructions
<jancoow>
ewm
<jancoow>
flashing a bootloader does not require fuses to be changed
<Haohmaru>
unless it does ;P~
<Haohmaru>
the other thing is lockbits, if they are implemented just like the fusebits
<Haohmaru>
it is often not a bad idea to lock the bootloader
<Haohmaru>
i don't know
<Haohmaru>
on avr you 100% need to change the fuses for a bootloader, because the bootsector is at the end of the flash, the chip needs to know you want it to begin executing from there, instead from the beginning
<Haohmaru>
but on arm i think this isn't the case and the bootloader can be at the beginning, or somewhere in the middle or $wherever
<jancoow>
its at the beginning
<Haohmaru>
or perhaps it's in the hands of each $vendor
<jancoow>
it's our own bootloader
<Haohmaru>
right
<Haohmaru>
i haven't written a bootloader for arm yet ;P~
<jancoow>
but did you for your leg?
<Haohmaru>
i did for xmega
<Haohmaru>
;P~
<jancoow>
you dont get the joke :(
<Haohmaru>
i got it
<jancoow>
oh
<jancoow>
was reading about swo/tdo a bit
<jancoow>
is that just uart?
<Haohmaru>
uart is async
<Haohmaru>
SWD already has a clock in there, so these could be sync'ed to it
<jancoow>
but we don't connect those pins and i've neither a clue how you can connect that to your mcu
<Haohmaru>
yeah i looked into that and my impression was kinda "meh"
<jancoow>
okay
<Haohmaru>
i ended up making a custom SWD connector with additional pins for a normal UART
<Haohmaru>
since there are plenty on the same54
<Haohmaru>
iirc 8
<karlp>
jancoow: swo can be in NRZ or manchester, and yes, in NRZ mode you can read it with just a normal uart.
<Haohmaru>
ah, fancy
<karlp>
and it's awesome and you should totally use trace if you have it. one more pin totally worth while.
<Haohmaru>
manchester would help if you.. don't wanna get desync issues
<Haohmaru>
or if you have to run it thru AC-coupling
<jancoow>
it saves us a sercom
<jancoow>
karlp cool!
<Haohmaru>
i had too much sh*t on my head so i didn't look into the swo thing deeply
<jancoow>
are you afraid to swear?
<Haohmaru>
no?
<jancoow>
sh*t, f
<jancoow>
;p
<Haohmaru>
that's how i write these words, i don't even think about it.. muscle memory
<jancoow>
must be from the usa ;p
<Haohmaru>
nope
<jancoow>
oh
<jancoow>
sweden
<jancoow>
?
<Haohmaru>
there might be kids in here so i try to not be as vulgar as MTV ;P~
<Haohmaru>
nope, .bg
<jancoow>
mtv?
<Haohmaru>
the "music" television
<Haohmaru>
which used to.. play music videos
<jancoow>
oh
<jancoow>
does that still exist?
<Haohmaru>
sure it does
<jancoow>
never seen it
<jancoow>
must be to young
<Haohmaru>
there probably ain't no kids on #openocd unless they got the name wrong, but i mean in general on the internetz
<Haohmaru>
on the other hand, my cat at home often eyeballs the computer and she might just be able to read, who knows
<karlp>
jancoow: saves you a sercom? if you meant using swo as a debug port, sure.
<karlp>
I highly recommend using swo as a debug port, because you can get so much more out of it than just printf.
<jancoow>
karlp ye i meant that
<jancoow>
we are using it for our automated test tool
<jancoow>
uart
<Haohmaru>
i should look into SWO moar
<jancoow>
Haohmaru lol
<jancoow>
guess what
<jancoow>
at91samd eeprom 4096 exist
<jancoow>
and at91samd bootloader too
<jancoow>
lol
<jancoow>
easy as that
<bencoh>
PaulFertser: you guessed correctly, extended-remote didn't help with hwthread
<bencoh>
gdb still reports only one thread
<Haohmaru>
jancoow meaning?
<bencoh>
PaulFertser: ohwell, I didn't think it would, but specifying -coreid for every core at target creation fixed it
<jancoow>
Haohmaru setting eeprom size
<jancoow>
ugh, now I get an error when I want to program our samr35j18b
<jancoow>
Error: Couldn't find part corresponding to DID 1081022b
<Haohmaru>
o_O
<Haohmaru>
is that from openocd?
<jancoow>
yes
<Haohmaru>
did you happen to check whether openocd supports this chip (or its family) ?
<jancoow>
well it is a atsaml21
<jancoow>
but with the semtech chip
<jancoow>
but 100% the same
<jancoow>
it's just a two in one chip
<Haohmaru>
that doesn't matter if openocd doesn't know about it
<jancoow>
oh
<Haohmaru>
(yet)
<Haohmaru>
new chips come up all the time, and then someone needs to teach openocd how to deal with them
<jancoow>
good to know
<jancoow>
we have to produce 2500 with our tool next month lol
<jancoow>
how can I tell?
<Haohmaru>
that sort of info should be in the documentation, lemme see
<Haohmaru>
(at worst, dig thru the source code)
<jancoow>
shouldnt it be a config
<Haohmaru>
i don't actually know if that error means what i assumed it means
<bencoh>
it should be a .cfg file in share/
<bencoh>
and if it's not supported, then you probably could just add support for it in one of the .cfg tcl file
<jancoow>
i'm using the at91samdXX.cfg
<jancoow>
bencoh how?
<jancoow>
target file?
<bencoh>
have a look at the various example there, yeah
<Haohmaru>
"at91samd: All members of the ATSAM D2x, D1x, D0x, ATSAMR, ATSAML and ATSAMC microcontroller families from Atmel include internal flash and use ARMs Cortex-M0+ core."
<Haohmaru>
this is from the user guide
<jancoow>
Haohmaru yes, but
<jancoow>
atsamr had an older series
<jancoow>
atsamr21 afaik
<bencoh>
I see atsaml1x.cfg for instance
<jancoow>
which is not a atsamr34 or 35
<Haohmaru>
i assumed "DID" is "Device ID"
<Haohmaru>
and that openocd uses that to confirm that the chip it's talking to is actually the chip you intended to talk to
<jancoow>
okay okay
<jancoow>
set _CPUTAPID 0x4ba00477 happens in the script
<Haohmaru>
but this error message could be saying maybe one of two different things
<jancoow>
maybe I should override it idk
<Haohmaru>
1) openocd knows the chip and expects to get 1081022b from it, and it doesn't
<Haohmaru>
2) openocd receives 1081022b from the chip and tells you it doesn't know a chip with that ID
<Haohmaru>
so you should look at the messages before this error to figure out what the context was
<jancoow>
I can verify that with atmel studio
<jancoow>
lets crank up windhoos again
<jancoow>
device signature is 0x1081022B
<Haohmaru>
right
<jancoow>
0x10810214 is the ATSAML21G18B
<Haohmaru>
so that's the DID (device ID)
<Haohmaru>
are any of those two special numbers in the .cfg ?
<jancoow>
they really where to lazy to add samr35j18b?
<jancoow>
common..
<Haohmaru>
$time a resource
<Haohmaru>
* is a resource
<Haohmaru>
if you're not lazy you can add it ;P~
<bencoh>
maybe it wasn't released back then, or it wasn't listed, or they thought it would be different
<jancoow>
the comment littarly says /* SAMR34/R35 parts have integrated SAML21 with a lora radio */
<Haohmaru>
more like.. people add what they care about, if they are nice and happen to have more time they may add some additional things besides what they wanted
<jancoow>
fair enough
<jancoow>
oh they dont allow pull requests on github
<Haohmaru>
i think the developement was on this gerrit thing