boru has quit [Killed (NickServ (GHOST command used by boru`))]
boru` is now known as boru
thinkfat_ has joined #openocd
thinkfat has quit [Ping timeout: 252 seconds]
ericonr has quit [Quit: WeeChat 3.1]
ericonr has joined #openocd
ericonr has quit [Client Quit]
ericonr has joined #openocd
tsal_ has quit [Ping timeout: 252 seconds]
tsal has joined #openocd
<clever>
boru: getting back into the linux debug again, thanks to the hard breakpoint, i can quickly reset after a crash, so i'm using nexti instead
crabbedhaloablut has quit [Remote host closed the connection]
crabbedhaloablut has joined #openocd
nerozero has joined #openocd
rue_shop2 has quit [Ping timeout: 250 seconds]
Haohmaru has joined #openocd
Guest90 has joined #openocd
rue_shop2 has joined #openocd
<boru>
You're welcome.
<clever>
boru: turns out, the bug was my DTB being 16mb
<clever>
the old bootloader made it 4kb bigger, to make room for adding nodes
<clever>
the new bootloader was working under an MMU, so i had to define the size/location ahead of time, and just went with 16mb
<clever>
i think the initial mappings linux setup, are not big enough to map a 16mb DTB, so it page-faults while parsing it
<clever>
and the pagefault handler hasnt been setup yet
<clever>
and without DTB parsing, it had no uart to complain on
<clever>
and after that, there was some issues due to IRQ's being left unmasked
<clever>
boru: now i have an entirely different and fun problem, i added a simple-framebuffer node at 128mb into ram, and now the sd card has just stopped working
<clever>
the uart too
Guest90 has quit [Quit: Client closed]
tarekb has joined #openocd
_franck_5 has joined #openocd
_franck_ has quit [Ping timeout: 240 seconds]
_franck_5 is now known as _franck_
_franck_8 has joined #openocd
<karlp>
what have you got in your dtb that exceeds 16MB?
_franck_ has quit [Ping timeout: 260 seconds]
_franck_8 is now known as _franck_
<Haohmaru>
should i inform microsh*t that their .svd has at least one flaw that makes it unable to generate legit headers?
<Haohmaru>
or the svd police
<karlp>
you can try, they may or may not care.
<Haohmaru>
their own headers are not generated from the .svd, but probably from the .atdf (which is a similar format from atmel which they used on avr and such)
<Haohmaru>
but maybe this "flaw" isn't a problem in C, not sure
<Haohmaru>
can you have an instance of struct A, named A?
<Haohmaru>
but that's offtopic.. i also saw some sketchy newlines in ST .svd files, but i don't remember
<Haohmaru>
i should collect some more from different vendors
eduardas has joined #openocd
gnom has quit [Remote host closed the connection]
gnom has joined #openocd
<Steffanx>
In my experience microchip is pretty helpful with such simple cases Haohmaru
<Haohmaru>
yeah, they usually reply, altho last time i needed to use the support, i had to play "mazerunner" on their website to find it
<karlp>
Steffanx: normally they're pretty reluctant to actyually fix svd file though, as it "breaks" downstream generated code.
<karlp>
so everyone carries a stack of patches on top of them
<Haohmaru>
yeah that's perfectly understandable
<Haohmaru>
but i don't think atmel made their headers from the .svd, but from the .atdf instead
<Haohmaru>
so maybe they won't care
sYCH3L has joined #openocd
danergo has joined #openocd
<danergo>
o/
<danergo>
is this the right place to ask some help/guidance with OpenOCD?
<karlp>
it is
<danergo>
perfect, thx
<danergo>
I'm trying to flash a CC2652 chip from TI with OpenOCD via Raspberry's GPIO (or SPI, or whatever suitable).
<olerem>
if it is still not working, then scope is the way to go
<danergo>
maybe my chip is not responding correctly to these magic bytes and doesn't switch itself into 4pin JTAG
<olerem>
sure, there are options like: the chip is flashed and this pins are muxed for something else. the chip is protected and jtag is disabled. or there is some wrong freq or voltage level. or something is not properly connected
<olerem>
so, you have to work on this checklist and limit possible reasons :)
<danergo>
hm. one more question and I'll go hunting :)
<danergo>
is cjtag implementation planned in the near future?
<olerem>
not if someone not starting doing it :)
<danergo>
if I have these equipments (launchpad, scope, analyzer) can I do it easily, or it's not that straightforwarD?
<olerem>
danergo: if i would start doing it, i would copy/paste swd code and hit it untill it will start working for cjtag
<olerem>
and yes, analyzer would play essential role in this kind of work
<danergo>
okkay, thank you so much!
<danergo>
I'll see how much time I'll have for this :)
<olerem>
danergo: it would be great if you'll do it. even if you can't implement everything, post the code, maybe someone else can continue it
sYCH3L has quit [Quit: Leaving]
PaulFertser has quit [Read error: Connection reset by peer]
PaulFertser has joined #openocd
<danergo>
okay, I'll see how can I proceed
<PaulFertser>
danergo: that said, if you connect full jtag you'll probably be able to switch from cjtag mode and use openocd as it is.
<karlp>
that's a "expected to work path" danergo
<karlp>
vs saving two pins and doing a bunch of sw work.
<danergo>
agreed
<danergo>
I just have to use a proprietary HW&SW which might "accidentally" uses the TDI and/or TDO pins for something else
<danergo>
and in this case both paths are bunch of sw/hw work
<danergo>
because I
<danergo>
a.) have to code the cJTAG for OpenOCD or
<danergo>
b.) have to design my PCB to apply some hw switch onto TDI/TDO (programming mode vs normal mode)
<danergo>
or
<danergo>
c.) losing the remote swupdate option and apply a jumper onto TDI/TDO, and use OpenOCD as-is with 4pin JTAG
<danergo>
anyway, I have some progress now with normal JTAG:
<danergo>
Info : BCM2835 GPIO JTAG/SWD bitbang driver
<PaulFertser>
danergo: yes, it's all fine, you can add ; reset before ; shutdown to let the target run but other than that flashing seems to be working nicely.
<karlp>
(it opened _three_ ports, and they're all for different purposes, you can turn them off as you see fit if you don't need them, or bind them to limited addresses)
<PaulFertser>
danergo: it failed but not due to reset.
<danergo>
yes, you are right. same result even without reset :O
<danergo>
tried detaching power from target, and checked the connections, all are good
<karlp>
are those sections in your image as you expect?
<PaulFertser>
You gotta experiment a bit.
<danergo>
actually it's not my image, it's a precompiled one which I know is working on this device when is flashed via XDS110
<danergo>
is my srst config OK?
<karlp>
goodo, I hadn't seen the one that succeeded flashing anyway.
<PaulFertser>
danergo: probably it enables some watchdog or probably your connections are not ideal and need some series resistors or probably more ground lines can help.
<PaulFertser>
danergo: well, if you have connected physical reset line between rpi and the target, yes. But apparently it doesn't work properly, might be a limitation of current support for this target, can't tell.
<danergo>
aham
<PaulFertser>
danergo: rpi uses high drive so it might provoke ringing on the lines. You're supposed to 'scope the signals and see if additional series termination is necessary or not.
<danergo>
okay, I'm checking it
danergo has quit [Quit: Client closed]
danergo has joined #openocd
<danergo>
strange. TCK, TMS and RESET pins of target are all high
<danergo>
3V3
<danergo>
(without connected to RPI)
<danergo>
those have to have a series resistor?
<danergo>
or not?
<danergo>
wow, I haven't done anything and now it's working again :O
<danergo>
(without the reset). with reset, those invalid ACKs came back:
<danergo>
1: target was in unknown state when halt requested
<danergo>
2: adding extra erease range, xyz
elpee has joined #openocd
<elpee>
hi everyone, I have a strange situation where the default `adapter srst delay 100` of stm32l0.cfg is too long on an STM32L082CZ with openocd 0.11.0-rc2 on debian bullseye. But I do not quite understand a how a delay after the nSRST signal is de-asserted can be _too long_? Is there only a marginal window of opportunity for openocd to halt after
<elpee>
reset? Does anybody have any references to point me in the right direction to understand how this works? Thanks in advance!
tarekb has quit [Quit: Leaving.]
Haohmaru has quit []
elpee has quit [Ping timeout: 256 seconds]
_franck_4 has joined #openocd
_franck_ has quit [Ping timeout: 265 seconds]
_franck_4 is now known as _franck_
<danergo>
folks, I have examined my reset issue. (after srst deassertation, I got error messages like "Debug regions are unpowered, an unexpected reset might have happened"
<danergo>
for some reason after srst deassertation, it calls "jtagdp_transaction_endcheck"
<danergo>
this jtagdp stuff seems related to reset, if I skip reset, it's not included in the log
<danergo>
guys, if I disable the srst, it seems working quite okay. can I trust in this line?
<danergo>
Warn : Only resetting the Cortex-M core, use a reset-init event handler to reset any peripherals or configure hardware srst support.
<danergo>
trust== does it reset the CPU, or I'll have to take care of that?
_franck_9 has joined #openocd
_franck_ has quit [Ping timeout: 245 seconds]
_franck_9 is now known as _franck_
JakeSays has quit [Ping timeout: 252 seconds]
JakeSays has joined #openocd
Thomas3 has joined #openocd
<Thomas3>
Hi everyone. I was here a few days ago and got some help with connecting to a STM32G0B1.
<Thomas3>
Well, it does connect and programm, and I always got a undefined exception. now I found that because its only flashes the first few hundred bytes and then fails :)
<Thomas3>
Any thoughts on that? Any possible mistake on my part or should I file a bug?
nerozero has quit [Ping timeout: 252 seconds]
Thomas3 has quit [Quit: Client closed]
sbach has quit [Read error: Connection reset by peer]
sbach has joined #openocd
<PaulFertser>
danergo: trst means jtag state machine reset, it shouldn't be related to target reset really.
sbach has quit [Ping timeout: 252 seconds]
sbach has joined #openocd
tarekb has joined #openocd
eduardas has quit [Quit: Konversation terminated!]
tarekb has quit [Read error: Connection reset by peer]