08:22 <philflieger> hello

08:25 <philflieger> I have trouble to connect to my ST-Link (V2) with openocd. Maybe someone can help me?

08:58 <karlp> well, not if they don't say anything and leave.... :|

13:30 <Haohmaru> "mon reset halt" - does this take into account something from gdb or from the .elf being loaded? or it simply just resets the chip?

14:16 <PaulFertser> Haohmaru: everything you do with "mon" goes behind gdb's back.

14:17 <PaulFertser> Haohmaru: on "reset halt" OpenOCD uses vector catch to stop at reset exception handler and then resets the target.

14:18 <Haohmaru> x_x

14:22 <Haohmaru> i'm making a bootloader for cortex M4, and when it should jump to the firmware - sh*t freezes.. so i ran gdb-multiarch with "tui" and loaded the firmware.elf, when i power on - i know the bootloader works, if i pause i see in gdb a low address so this looks okay.. when the bootloader jumps to the firmware - sh*t f*cks up, then if i break i see the HardFault handler in the firmware

14:22 <Haohmaru> thing is, in this situation, when i do "mon reset halt" and then "continue" - it doesn't start my bootloader

14:23 <Haohmaru> i keep seeing that hardfault handler

14:23 <Haohmaru> so the only way to get thru the bootloader again is to power OFF and that's highly inconvenient

14:23 <Haohmaru> ...afaik

15:12 <karlp> I would suspect yoru actual problem is you enabled irqs in the bootloader that your app isn't handling, or isn't handling in time.

15:13 <Haohmaru> the bootloader was made by... copying an already working "standalone" firmware for this board, and then changing stuff to make it into a bootloader

15:14 <Haohmaru> so yes, i removed a ton of the firmware things, but it surely uses interrupts, usarts, and some other crap

15:15 <Haohmaru> however, i made it so that the jumping to firmware happens in the very beginning of main() before i initialize the usarts even

15:16 <Haohmaru> ehm, more like.. the bootloader checks for a "magic" value in RAM, only then it can jump to the firmware, otherwise it continues forward and initializes a pile of things... so when i tell it to run the firmware - it "configures" this "magic" and does a NVIC_SoftReset(), then the top of main() has the checks and does the jumping

15:17 <Haohmaru> at least this was the plan..

15:18 <Haohmaru> so before the jump to firmware, in main() i only touch some settings related to brown-out detection, and i use a CRC32 and a SHA hash peripheral

15:19 <Haohmaru> the SHA code is from $vendor, the rest is mine..

15:19 <Haohmaru> afaik the SHA uses DMA stuff, i don't even call the $vendor init() at the top of main()

15:20 <Haohmaru> bluh

15:24 <Haohmaru> can openocd do a reset via the RESET pin?

15:25 <Haohmaru> i can't get the chip to re-start running from the bootloader once i get it into this frozen state

16:19 <Haohmaru> i can't even find an __enable_irq() in my code, yet interrupts work o_O

16:19 <Haohmaru> wtf is going on

16:20 <Haohmaru> are they ON by default or something?

16:20 <Mis012[m]> ok, so apparently if I define both the cpu AND the mem_ap, then I can run dap info?

16:21 <Mis012[m]> dap info 0 results in the familiar infinite loop

16:21 <Mis012[m]> but...

17:01 <Haohmaru> holy sh*t, the firmware started o_O

17:43 <Haohmaru> karlp you're right, my firmware was being ran and it was getting stuck after it prints a ton of sh*t to UART and the FIFO runs out of space and starts blocking wait

17:44 <Haohmaru> added __disable_irq() right before any switch between BL<->FW, and __enable_irq() early in main() for both

17:44 <Haohmaru> but it seems the interrupts must be enabled by default on the chip or i don't know wtf was going on

17:57 <Mis012[m]> PaulFertser: I managed to examine the RPM (which is not the boot core fwiw), but I get this if I try to connect with gdb (telnet to :4444 works fine)

17:57 <Mis012[m]> (gdb) target extended-remote :3333

17:57 <Mis012[m]> Remote connection closed

17:57 <Mis012[m]> Remote debugging using :3333

17:58 <Mis012[m]> oh, I see

17:59 <Mis012[m]> the RPM is at :3334

19:18 <PaulFertser> Mis012[m]: awesome progress

19:20 <Mis012[m]> does gcc's x command use instruction stuffing?

19:20 <Mis012[m]> it doesn't seem to behave nicer than the MEM-AP

19:23 <PaulFertser> You mean GDB? You can do "set debug remote 1" in gdb and see what exactly it sends, the protocol is documented in GDB Info under "Serial protocol" chapter.

19:26 <Mis012[m]> yes, gdb

19:26 <Mis012[m]> how do I still mistype it as gcc

19:49 <Mis012[m]> fwiw it seems that again I can access the addresses on that AHB bus where the DAP stuff is

21:25 <Mis012[m]> Info : 191 301 cortex_m.c:912 cortex_m_poll(): [chip.rpm] external reset detected

21:26 <Mis012[m]> PaulFertser: does this mean SRST is somehow being pulled down?

21:29 <Mis012[m]> should be high unless there's something suspicious going on with the singal while on the PCB

21:30 <Mis012[m]> but swd signals work fine

21:37 <Mis012[m]> well, I guess that CPU shouldn't be running on boot

21:37 <Mis012[m]> and there is a reset signal for it... that I can't access afaict :/