NishanthMenon changed the topic of #openocd to: this is the place to discuss all things OpenOCD | Logs: https://libera.irclog.whitequark.org/openocd/
akaWolf has quit [Ping timeout: 245 seconds]
crabbedhaloablut has quit [Remote host closed the connection]
crabbedhaloablut has joined #openocd
Krazubu has quit [Quit: My Mac Pro has gone to sleep. ZZZzzz…]
tsal has quit [Ping timeout: 256 seconds]
tsal has joined #openocd
tlwoerner has joined #openocd
akaWolf has joined #openocd
akaWolf has quit [Ping timeout: 240 seconds]
akaWolf has joined #openocd
crabbedhaloablut has quit [Remote host closed the connection]
crabbedhaloablut has joined #openocd
Bertl_oO is now known as Bertl_zZ
nerozero has joined #openocd
zjason` has joined #openocd
zjason has quit [Ping timeout: 240 seconds]
Hawk777 has joined #openocd
Haohmaru has joined #openocd
Hawk777 has quit [Quit: Leaving.]
jobroe has joined #openocd
wolfshappen has quit [Ping timeout: 240 seconds]
Krazubu has joined #openocd
jobroe has quit [Quit: Konversation terminated!]
thinkfat_ has joined #openocd
<PaulFertser> orzel: hey
<PaulFertser> Krazubu: grab a 'scope I guess, probably the signal integrity is not good enough if the communication is unstable like that.
<PaulFertser> Krazubu: also, as I said before, with most reasonable cortex-m targets you should be able to reliably talk to it with reset pulled low.
<Krazubu> I don't have access to an oscilloscope, only logic analyser, however I didn't try to pull reset low, gonna try now
<PaulFertser> Krazubu: what is your target MCU again?
<PaulFertser> Krazubu: it's hard to judge signal integrity without an oscilloscope :(
<Krazubu> it's an EFR32GM21 from Silabs
<Krazubu> EFR32 MGM12 sorry
<PaulFertser> Hm, I can't tell if it should answer under reset or not. If it answers occassionally while running its firmware it might mean it's entering the sleep mode every now and then.
<PaulFertser> Unless it's a signal integrity issue indeed.
<PaulFertser> But trying under reset is easy and might give additional datapoint.
<Krazubu> sure
thinkfat_ has quit [Ping timeout: 268 seconds]
thinkfat_ has joined #openocd
<Krazubu> pull down doesn't help
<Krazubu> this is the best I get http://pastie.org/p/56aiLMM98v89YoGXDwkYWM
<Krazubu> but most of times it detects wrong cpu or nothing
<PaulFertser> Krazubu: are you using jtag, not swd?
<Krazubu> trying both
<PaulFertser> Krazubu: do you have series resistors on data lines?
<Krazubu> swd is not working anymore at all
<Krazubu> nop
<PaulFertser> Krazubu: rpi driver defaults to highest drive strength so it might result in ringing. You can't tell if it's exactly the case without an oscilloscope but adding 47 Ohm in series on every data line shouldn't harm.
extor has quit [Ping timeout: 256 seconds]
<Krazubu> ok gonna look into that thx
<PaulFertser> Krazubu: using something around that value should work too.
<PaulFertser> Krazubu: even ten times more
<PaulFertser> Krazubu: another thing to try would be 100 kHz adapter speed. Plus resistors. Plus more ground lines.
thinkfat_ has quit [Quit: Konversation terminated!]
thinkfat_ has joined #openocd
extor has joined #openocd
Bertl_zZ is now known as Bertl
<orzel> PaulFertser: Here's what it looks like, still failing https://pasteboard.co/nOhQDcMofCcR.png
<orzel> The red part is "noreply"
<orzel> it doesn't matter if i pull reset to low or not
<orzel> Everything looks fine to me.... but no answer
<karlp> are you sure the target actualyl works?
<orzel> The board works well, yes. I'm 100% sure the mcu is not dead
<PaulFertser> orzel: probably it has some SWD disabled mode then?
<orzel> That's what i'm afraid, but i dont know how to check
<orzel> the datasheet is only in chinese :/
<PaulFertser> Those MCUs with documentation only in Chinese are sketchy :/
<orzel> Still, there's this swd i/o port, it must be of some use
<orzel> I'm no familiar with arm/swd, i dont know how 'disabled' is done on other ARM
<PaulFertser> orzel: I would try to start OpenOCD in a loop so that it would be trying to connect and then randomly power cycled the board.
<PaulFertser> orzel: in case it can't communicate under reset and some firmware disables SWD early.
<PaulFertser> orzel: btw, does the datasheet mention some BOOT pin?
<orzel> yes, there's a pin "boot0"
<orzel> just next to swclk
<PaulFertser> orzel: can you check if it's hard-pulled to Vcc?
<orzel> "boot0 XXXXXX FLASH XXXXX" in the doc
<orzel> xxx= chinese
<PaulFertser> Or probably to GND.
<PaulFertser> What I'm really wondering if it's possible for you to pull BOOT0 high externally.
<PaulFertser> Will it go high if you connect it via e.g. 1k resistor or is it just connected to GND directly?
<PaulFertser> orzel: stm32f0 uses that pin to enter UART bootloader mode. In that mode main firmware isn't running, and it's possible to talk to the target via UART and SWD.
<orzel> There's a signal on it
<orzel> With the voltmeter, it's not stable
<PaulFertser> That's odd
<orzel> With signal analyzer, it's mostly +vcc, but there are some burst of signals to ground
<PaulFertser> I'd try pulling it high with some safe value like 1k and power cycle the board. To see if the main firmware boots.
<orzel> i'll try. Not easy, small smd component, and i dont think this pin is routed to some easily i/o, as for the swd
<PaulFertser> I do not have any other ideas. Is the pinout pin-to-pin compatible with stm32f030 ?
<PaulFertser> In this case probably replacing the whole MCU can make sense.
<orzel> mine is ssop28
<PaulFertser> oh
dliviu has quit [Ping timeout: 268 seconds]
dliviu has joined #openocd
dliviu has quit [Quit: Going away]
dliviu has joined #openocd
bynarie has left #openocd [Leaving]
thinkfat_ has quit [Ping timeout: 240 seconds]
<braunr> hello
<braunr> i have an stm32f7 that seems to always enter its embedded boot loader
<braunr> and never load anything from flash
<braunr> i can't find how to change that behavior so the reset fetches its vector from flash instead
<braunr> apart from boot pins, what could cause that ?
<Haohmaru> lack of "firmware" maybe?
<braunr> no it's there and i can boot into it by forcing pc
<braunr> i think there's an option somewhere that forces the use of boot_add1 and not boot_add0
Bertl is now known as Bertl_oO
<bencoh> isn't there some flash/"nvram" bit?
<Krazubu> PaulFertser I noticed the default cfg for raspberry 3 reads it's calibrated for the stock 700MHz, but mine is changing dynamically, I don't know if openocd takes care of that or if I must do something
<braunr> bencoh: probably but i can't find it
<braunr> i found nDBOOT but the manual says it should be ignored in my case
<PaulFertser> Krazubu: openocd doesn't try to care, it just bitbangs and adds fixed delay.
<braunr> ok problem solved, it was indeed a problem with nDBANK and nDBOOT
<bencoh> :)
Boban has joined #openocd
<Boban> Hi
<Boban> I'm trying to use the OpenOCD 'nand list' command to list the available flash devices. I want to know where this command should be used. Should it be a command-line argument or in a board/target file?
<karlp> you can do either, they're equivalent functioanlly.
<karlp> most can even be done interactively via telnet port
<Boban> Can they be used while the target is halted?
<karlp> that depends on the command, not how it is sent.
Haohmaru has quit []
<Boban> I'm trying to send this command through gdb but it's not being recognized.
<Boban> Can it be sent through gdb?
<bencoh> you need to prefix it with monitor
<Boban> I'm getting ' invalid subcommand "list" ' when I type monitor nand list in gdb
<bencoh> does it work from telnet?
<Boban> I use gdb to debug my code
<Boban> I'd like to get it working through gdb if possible
<bencoh> sure, but the question still stands; have you tried from telnet? just it make sure it's not a version issue, or the subcommand missing for some non-obvious reason
<Boban> ok
<bencoh> s/it make/to make/
Hawk777 has joined #openocd
nerozero has quit [Ping timeout: 240 seconds]
<karlp> try just "mon help" to and check the list
<karlp> is it "flash list" ? not "nand" list?
<Boban> telnet also shows invalid subcommand list
<Boban> OpenOCD user's guide mentions 'nand' list as the command
<Boban> Yes flash list is also a command but it's used for NOR flash. I'm using a NAND flash
wingsorc__ has quit [Quit: Leaving]
<Boban> I don't see 'nand list' or 'nand probe' when I type in 'monitor help'. Are there any alternate commands for these?
<bencoh> Boban: which version of openocd is that?
<Boban> it's 0.10
<Boban> 0.10.0
<PaulFertser> Do you really need to use a version that outdated? You should be reading the manual from that version to see the matching commands in that case.
<PaulFertser> Boban: what's your target?
<Boban> The user guide for 0.10.0 also mentions the same commands
<PaulFertser> Then probably your target config just doesn't define any nand memory.
<orzel> 0.10.0 is so outdated ? current is 0.11.0..no ?
<PaulFertser> orzel: current is git master branch :)
<orzel> ah :)
<bencoh> 0.10 is from 2017 :)
Boban has quit [Quit: Client closed]
wolfshappen has joined #openocd
Steffann is now known as Steffanx
<orzel> release early, release often !
Pokey is now known as ahorner
ahorner is now known as Pokey
sbach has quit [Read error: Connection reset by peer]
sbach has joined #openocd
Guest4479 has joined #openocd
<Guest4479> I seek help updating my config files.  I have been using an older version of openocd with mods for stm32g0 support.  Since those are now in the new release 0.11, I am trying to move to the new goodness.
<Guest4479> My old config looks like this:
<Guest4479> source [find /usr/local/share/openocd/scripts/interface/stlink.cfg]
<Guest4479> source [find /usr/local/share/openocd/scripts/target/stm32g0x.cfg]
<Guest4479> gdb_memory_map enable
<Guest4479> gdb_flash_program enable
<Guest4479> hla_serial "\x55\x3f\x66\x06\x48\x3f\x57\x54\x12\x27\x07\x3f"
<Guest4479> gdb_port disabled
<Guest4479> tcl_port disabled
<Guest4479> telnet_port disabled
<Guest4479> init
<Guest4479> jtag configure stm32g0x.jrc -event setup "jtag tapenable stm32g0x.cpu"
<Guest4479> dap create CPU -chain-position stm32g0x.cpu
<Guest4479> And I would use something like this:   openocd -d0 -f openocd-1.cfg -c "program adc-v.bin 0x08000000 verify reset exit"
<Guest4479> Now I have an error:
<Guest4479> Error: The specified debug interface was not found (hla)
<Guest4479> The following debug adapters are available:
<Guest4479> 1: jlink
<Guest4479> 2: buspirate
<Guest4479> I'm sure my approach is probably flawed.  Please show me the way.
<Guest4479> I need the serial number to distinguish between multiple stlink devices, programming multiple chips.
<Guest4479> It seems that both the stlink.cfg and stm32g0x.cfg files reference hla.
<Guest4479> Has that been absorbed by jlink or buspirate or some other thing?
<PaulFertser> Guest4479: there's no problem with your config, there's a problem with your self-compiled openocd binary.
<PaulFertser> Guest4479: guess you didn't have libusb-dev installed so stlink support wasn't enabled during configure stage.
<PaulFertser> Guest4479: also please never send more than 2-3 lines in public channels, use pastebin instead.
<PaulFertser> Regarding your config, you should be able to omit "/usr/local/share/openocd/scripts/" (openocd knows where it's installed), gdb_memory_map and flash_program are already enabled by default.
<PaulFertser> Guest4479: and you do not need jtag configure and dap create commands as target config should already include that.
<Guest4479> Thank you.  I will comply with shorter posts.  My apologies.
<PaulFertser> np :)
<Guest4479> I'll go check my build again.  I know libusb-dev is installed.  Maybe I need to turn it on.
<PaulFertser> Guest4479: it's autoenabled if pkg-config tells it's available.
<PaulFertser> Guest4479: probably it's called libusb-1.0-dev
<Guest4479> OK.  I'll go figure that out.  Thanks for the config tips!
<Guest4479> Well, you were absolutely correct.  The build environment did not have libusb.  Thanks again.
<PaulFertser> Guest4479: enjoy :)
Guest4479 has quit [Quit: Client closed]