sbach has quit [Read error: Connection reset by peer]
sbach has joined #openocd
nerozero has joined #openocd
xantoz has quit [Read error: Connection reset by peer]
xantoz has joined #openocd
<jancoow>
Lol we bought a segger base as replacement for our atmel ice to finally have more then 4 breakpoints and faster flash time; turns out that that still does not work with openocd
<antto>
hm?
<antto>
is that for SWD targets?
<PaulFertser>
jancoow: I do not see any reason why that can differ depending on an adapter.
<PaulFertser>
jancoow: hw breakpoints are limited by the target hardware, obviously. And the flash time of an MCU is usually limited by the flash speed rather than the communication link speed.
<PaulFertser>
Same for JTAG and SWD targets.
Hawk777 has quit [Quit: Leaving.]
xantoz has quit [Ping timeout: 256 seconds]
xantoz has joined #openocd
<jancoow>
It's for SWD yes
<jancoow>
The SWD interface to the jlink is rather slow and I can confirm that
<jancoow>
It does not allow over 5mhz
<jancoow>
And the j link offers software breakpoints
<antto>
because for SWD according to my limited impression, the atmel-ice "performs" equally as a SWDAP-based debugger (which is significantly cheaper)
<jancoow>
However the jlink comes with its own gdb server so I guess I don't need openocd anymore
xantoz has quit [Ping timeout: 240 seconds]
<jancoow>
Flash times of 1.5seconds compared with 11 is significantly faster :)
<PaulFertser>
jancoow: OpenOCD could support flash breakpoints with any adapter but I do not remember anyone implementing that.
<PaulFertser>
How flashing can be made significantly faster is beyond my understanding.
<jancoow>
The atmel ice only goes to 400khz
<jancoow>
Err 2 mhz
<jancoow>
While this segger goes to 16mhz
xantoz has joined #openocd
<PaulFertser>
jancoow: heh, 2 MHz is kind of slow, yes. I'm surprised Atmel releases adapters that are so much slower than any ft232h thing.
<PaulFertser>
Those are working up to 30 MHz.
<PaulFertser>
jancoow: but going up to 16 MHz with jlink should work to speed up flashing with OpenOCD as well, right?
Krazubu has joined #openocd
tlwoerner has quit [Ping timeout: 256 seconds]
tlwoerner has joined #openocd
<jancoow>
PaulFertser their direct SWD speed is pretty slow and is only around 4mhz
<jancoow>
So yes, flash times are 4 seconds now
nerozero has quit [Ping timeout: 240 seconds]
<jancoow>
But not as fast as it should ;p so ye guess I need to use their gdb
nerozero has joined #openocd
<PaulFertser>
jancoow: so what makes jlink gdbserver able to flash fastter?
Krazubu has quit [Quit: My Mac Pro has gone to sleep. ZZZzzz…]
crabbedhaloablut has quit [Remote host closed the connection]
crabbedhaloablut has joined #openocd
Bertl_zZ is now known as Bertl_oO
Krazubu has joined #openocd
<jancoow>
dunno?
<jancoow>
Im sure its software limitied
<jancoow>
maybe they want to have you install their propitiatory stuff so they can check licenses
<jancoow>
because you can also get those jlink for a few bucks on alixpress..
<PaulFertser>
jancoow: are you sure OpenOCD doesn't reset the speed to a slower one for you when you're testing?
<PaulFertser>
jancoow: because some target files do that.
<PaulFertser>
jancoow: I'd be interested in making OpenOCD faster.
<jancoow>
I couldn't set it higher then 500khz
<jancoow>
then it would throw flash errors
<PaulFertser>
jancoow: huh, you never said. Please show the log.
<PaulFertser>
jancoow: what target is that?
<jancoow>
well I could set it; but it would throw errors inmediatily
<jancoow>
the target is WD
<jancoow>
SWD
<PaulFertser>
SWD is just a protocol, but what you describe sounds like a timing-sensitive bug in a flash driver.
<PaulFertser>
You can try higher speeds to do reading from flash or SRAM for testing.
<antto>
errors on faster speeds may also be due to electrical issues
<antto>
like, sketchy cables
<PaulFertser>
we're comparing same hardware here, just jlink gdb server vs openocd.
<jancoow>
it works fine when setting it higher in atmel studio
<jancoow>
and flash times prove that
<PaulFertser>
jancoow: without your input we can't improve openocd.
<jancoow>
I don't have the log on hand now
<PaulFertser>
jancoow: please consider sparing some time later on an interactive debugging session.
<PaulFertser>
So that we could try different things to pinpoint the bottleneck.
<jancoow>
I would love too; but have to take the tool home then
<jancoow>
I bought it at work
<PaulFertser>
It's not like you can't bring it home for a weekend?
<jancoow>
I might ye
Krazubu has quit [Quit: My Mac Pro has gone to sleep. ZZZzzz…]
Krazubu has joined #openocd
<Krazubu>
hi, I'm trying to access a STM32 F103 using cmsis-dap.cfg interface and stm32f1x.cfg, it connects fine, but when I try to see memory content using dump_image or mdb it onlo shows sequences of "e7 0f 00 20 1c 00 00 20"
<Krazubu>
only*
<Krazubu>
any idea what's going on ?
<Krazubu>
btw I know this data is wrong
<PaulFertser>
Krazubu: what address are you dumping from?
<Krazubu>
0, until 0x1FFFF
<Krazubu>
I just see in memory banks that flash is supposed to start @ 0x08000000, however output is the same
<PaulFertser>
Krazubu: hm, what is the state of BOOT1 pin? Are you probably trying to boot from RAM?
<PaulFertser>
Krazubu: and how do you know what's in flash currently?
<Krazubu>
hmmm I actually didn't check that not familiar with stm32, but I think I've seen what you're talking about here and there
<Krazubu>
it's a jlink OB clone, it has a working firmware currently
<Krazubu>
I'd like to backup and change its firmware
<Krazubu>
I've seen the "big" jlinks have jumpers for different states
<Krazubu>
so I'd have to short some pins to access flash content ?
<PaulFertser>
Krazubu: are you sure you tried dumping from 0x08000000 and it was the same?
<PaulFertser>
Krazubu: probably the flash is indeed read-protected
<Krazubu>
ok, so a mass erase might unlock it ?
<PaulFertser>
Krazubu: is that after "reset halt" ?
<PaulFertser>
Krazubu: what does "reset halt" tell you?
<Krazubu>
hmmm I don't remember actually, let me check, not sure I thought about halting it this time
<PaulFertser>
Krazubu: mass erase will unlock and erase and then you won't be able to read the existing firmware.
<Krazubu>
yeah that's the drawback, however I don't relly mind about losing the current one, my fear is just that I wouldn't know how to restore a working one
<PaulFertser>
Krazubu: how would you restore a working one if you do not have a dump?
<Krazubu>
I can find other firmwares elsewhere
<Krazubu>
but I'm not familiar with the way stm32 works
<PaulFertser>
stm32f103 can't be permanently locked anyhow.
<PaulFertser>
So what about "reset halt" output?
<Krazubu>
it was just a safety measure, that current firmware is faulty anyway
<Krazubu>
so, reset halt gives : target halted due to debug-request, current mode: Thread