<PaulFertser>
veverak: sure, please share the details of how exactly openocd doesn't work, use some pastebin.
<veverak>
the openocd connects to the v2, finds the cpu, but once I try to 'load' the binary from GDB, I am getting this: Error erasing flash with vFlashErase packet
<PaulFertser>
veverak: is your STLINK-v2 original or clone?
<veverak>
PaulFertser: fuu, it's old, I guess this one is clone
<PaulFertser>
veverak: I suggest you try without srst_only then, some clones have reset miswired.
<veverak>
(anyway, it works with the stutil SW, so I guess it should be OK?)
<veverak>
\o/
<veverak>
PaulFertser: IT WORKS
<veverak>
thanks :)
<PaulFertser>
veverak: I know there's a patched stlink v2 firmware which fixes reset on some of those clone, need it?
<veverak>
not really I guess?
<PaulFertser>
veverak: ok :)
<PaulFertser>
veverak: hardware reset is useful when the target is sleeping or multiplexing swd pins to something else.
<veverak>
yeah, but I hope that this will be temporary solution and I will get stlink-v3-mini
<veverak>
the PCB I have is even deisgned for it to be soldered in place..
<PaulFertser>
veverak: beware, with stlinkv3 ST apparently decided to fuck their customers and it'll only ever work with ST MCUs.
<veverak>
interesting
<veverak>
I do not mind now, but it is not "cool"
<veverak>
tbh I am kinda inclined to try blackmagicprobe
<veverak>
but no time for that yet
<veverak>
hmm, out of curiosity
<veverak>
PaulFertser: any favourite programmer?
<Haohmaru>
veverak i have an stlink3-mini which i don't need (altho i might be using its cable)
<Haohmaru>
on the other hand, it's cheap, probably cheaper than any shipping, unless you're in .bg
<Haohmaru>
i needed it as an SWD debugger, but it turned out it's locked to only ST chips, and mine isn't
<Haohmaru>
thus i have no use for it
<veverak>
I see
<veverak>
I kinda like that it has indegrated UART
<veverak>
(eve more, but I need something that has drivers for linux)
<Haohmaru>
yeah that was nice, i even added the STDC-14 port on my board because of it
<Haohmaru>
ended up buying an SWDAP-based debugger which also has UART, made a little adapter board https://i.imgur.com/BPHhvhm.jpg (the one on the right)
<veverak>
ool
<veverak>
cool
<Haohmaru>
and yeah, it surely works fine on linux, both the debugger and the additional UART
<karlp>
iirc someone has some options somewhere that you let you do different outputs, but it might have just been an svg-to-xxx conversion after the fact.
<Haohmaru>
i do have some mIRC scripts that visualise "signals" with ASCII from clipboard data
<Haohmaru>
veverak the debugger DAP-based in particular is kamami zl33prg
<Haohmaru>
not all DAP-based debuggers add the UART, beware
<Haohmaru>
while most folks here actually seem to recommend using jlink debuggers
<karlp>
for certain definitions of most...
<Haohmaru>
or at least they use those
<karlp>
I can't say that's the impression I have :)
<Haohmaru>
karlp what do *you* use? ;P~
<Haohmaru>
oh?
<Haohmaru>
jlink was the segger thing, right?
<karlp>
I use stlinks from dev boards, or whatever else came on the devboard
<Haohmaru>
true
<Haohmaru>
and stlink3 would've been wonderful if it wasn't ST-only, but i can't blame them
<Haohmaru>
there's also a very cheap option from segger too but "edu" .. limited to educational usage or some such crap
<bencoh>
olimex is in the same price range and isn't edu-limited ;)
<veverak>
well, I am student at university ...
<bencoh>
then go for it I'd say :)
<bencoh>
jlink is a great tool anyway (both with openocd and with segger's software)
<Haohmaru>
afaik the segger thing has the gdb server directly in the device
<Haohmaru>
which is.. fancy
<Haohmaru>
(hm, don't quote me on that0
<bencoh>
not with the usb jlink version at least
<bencoh>
(jlink-pro has an ethernet port though)
<Haohmaru>
or was that another debugger? i definatelly remember there were debuggers with gdb-server running inside
<bencoh>
jlink-pro, among others :)
<Haohmaru>
ah
<Haohmaru>
then you won't need openocd, you'd connect gdb directly to that
<Haohmaru>
afaiu
<Haohmaru>
hope they don't have any bugs there ;P~
<bencoh>
:]
<bencoh>
oh, something I've been willing to ask for a long time ...
<bencoh>
I added support for some chip and built the flash driver around the openflashloader firmware (yes, that segger thing) that was shipped with its SDK
<bencoh>
(it happens to be shipped with the segger tools as well)
<bencoh>
but it's not really mergeable as-is, for various reason
<bencoh>
1. I patched the firmware to BKPT instead of returning from the flash/erase functions
<veverak>
OT: oh god this Analog Discovery 2 thing is cool
<veverak>
(sorry, got new toy, happy about it so far :) )
<bencoh>
2. I'd need a way to get the proper erase/flash function addresses from openocd (sounds like it'd imply parsing elf at some point)
<bencoh>
3. I'd need to wrap the erase/flash functions with some code to avoid patching the binary (to BKPT at the end of execution), meaning I need some "free" space (not used by said firmware) in the working area
<karlp>
so you added support for openocd to use openflashloader api, which requires blobs from segger? rather than the normal implementing flash functions directly?
<bencoh>
(4. I'd need to load the firmware at some point)
<karlp>
I don't think you'll get very far trying to merge them. all the flash loader stubs are internal already, with sources in the tree, and there's been pushback in the past on using a third party library that provided debug, as it was viewed as just avoiding opensource.
<bencoh>
karlp: well, writing a flash driver for said chip was beyond the scope of what was indeed $here back then, and there were so many steps in the project (adding support was only the begining) that I prefered using said blob
<karlp>
I understand :) I just don't think you'll get very far trying to upstream it like that.
<bencoh>
s/indeed/nedeed/
<bencoh>
I suspected I'd get a similar answer to be honest :)
<karlp>
don't get me wrong, I think some of the openflash loader stuff looks pretty handy, but it's just duplicate at this point.
<karlp>
the xml config is basically a sideaffect of being closed source.
<karlp>
still a nice way of doing things for the user, IMO.
<bencoh>
actually I saw it more as a way to add (preliminary) support for missing devices to openocd
<karlp>
there's huge chunks of oocd that is just awful being in C :)
<karlp>
but, no my barrel of monkeys...
<bencoh>
especially considering some (many?) vendors ship an openflashloader firmware with their SDK
<PaulFertser>
bencoh: OpenOCD has facilities to upload firmware to target's SRAM and to call its functions already.
<PaulFertser>
bencoh: and of course it parses ELFs in generic code, giving flash drivers raw data and offsets.
<bencoh>
PaulFertser: I used that part as well obviously :)
<bencoh>
oh?
<bencoh>
I missed the second part then
<bencoh>
(when it comes to flash drivers at least)
<bencoh>
most examples I saw use some inline assembly code in the flash driver itself
<PaulFertser>
bencoh: you can take a look at e.g. src/flash/nor/lpc2000.c driver, it uses API functions from target's ROM even.
<PaulFertser>
bencoh: that inline assembly code is automatically included and uploaded to target's SRAM.
<PaulFertser>
bencoh: you can check git log for flash/nor and see how any new drivers were added. There usually is some code uploaded to target's SRAM, yes, and it's included in the binary. Not sure what particular detail you're missing there, please clarify.
<bencoh>
PaulFertser: I was talking about parsing a proper elf image (which could even be built in openocd tree, btw; in my case it came from the vendor)
<bencoh>
and uploading it along with some wrapper "algo"
<PaulFertser>
bencoh: an ELF image of what?
<bencoh>
a flasher firmware
<bencoh>
(basically what I explained before)
<PaulFertser>
bencoh: there's "load_image" command which parses and uploads. But why does it need to be an ELF image, can't you strip it to the loadable part and just put it to a SRAM location?
<PaulFertser>
bencoh: btw, the loaders are supposed to be PIC.
<bencoh>
I obviously used load_image to upload it, and target_run_algorithm() to run it ;)
<bencoh>
but I was looking for a generic/dynamic way to handle function addresses and available "working" space
<bencoh>
(where to allocate the temp data buffer, for instance)
<PaulFertser>
bencoh: I think the trick here is to not use ELF and then you'd be doing the same as the other drivers are doing.
<bencoh>
I guess so, but the point was to use the image as-is :)
<PaulFertser>
bencoh: reset-init event handler can be used to load the ELF then.
michalkotyla has joined #openocd
michalkotyla has quit [Quit: michalkotyla]
nerozero has quit [Ping timeout: 256 seconds]
Haohmaru has quit []
indy has quit [Read error: Connection reset by peer]
indy has joined #openocd
sbach has quit [Read error: Connection reset by peer]