Hi all. This is slightly different from the problem I had with the STM32F407. As others have been able to flash-program the STM32F427 on a "DISCO" board, I believe that this issue is related to a completely 'fresh' / unused device.
The device is soldered onto an adapter-PCB and connected to a 'bare minimum' circuit; eg. the necessary decoupling capacitors, VCAPs, SWDIO/SWCLK on JTAG-lock-pick Tiny 2 and a LED with a 1K2 resistor and a pull-down resistor on BOOT0. Here's a small session-snippet: ---8<-----8<-----8<----- > mdw 0x40023c00 4 0x40023c00: 00000000 00000000 00000000 00000000 > mdw 0x40023c10 4 0x40023c10: 00000002 0fffaaed 0fff0000 00000000 > mdw 0x40023c20 8 0x40023c20: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 > mdw 0x08000000 Failed to read memory and, additionally, failed to find out where in procedure 'mdw' Polling target stm32f4x.cpu failed, GDB will be halted. Polling again in 100ms Polling target stm32f4x.cpu succeeded again, trying to reexamine stm32f4x.cpu: hardware has 6 breakpoints, 4 watchpoints target state: halted target halted due to undefined, current mode: Thread xPSR: 0x01000000 pc: 0xfffffffe msp: 0xfffffffc --->8----->8----->8----- -What's interesting here, is that the FLASH_CR register is unlocked [0x40023c10 = 0x00000002]. Flash-memory protection has been switched off in FLASH_OPTCR [0x40023c14 = 0x0fffaaed]. Read-protection is off as well. I can manually set GPIOD->MODER to 0x55000000 (PD[15:12] = output), then I can change PD12 by writing to GPIOD->ODR or GPIOD->BSRRL / GPIOD->BSRRH. I can also read the entire range of CCM data RAM, the entire SRAM1, SRAM2 and SRAM3 without getting any errors. Dumping the registers show that r0 to r12 are all 0x00000000, sp is 0xfffffffc, lr is 0xffffffff and pc is 0xfffffffe. This indicates that a double-fault occurred, and that the initial values for both SP and PC would have been 0xffffffff, thus flash-memory most likely contain 0xffffffff everywhere. I've gone through all the RCC registers and all the FLASH registers, but have not found anything that looks wrong. The PLL is turned off, the CPU is running from the HSI, which is 16 MHz. AHB, APB1 and ABP2 are all running at 16 MHz directly from the HSI. Back to the double-fault. This indicates that the code-snippet sent from OpenOCD HardFaults when it's trying to read Flash-memory. I suspect that there might be a problem with some configuration-bit somewhere, such as a power-configuration, some enable-bit, speed-configuration or perhaps even the FLASH_ACR. I also expect that it's a setting that survives a power-cycle, since the DISCO boards can be programmed without this issue occurring. ... But it's interesting that the registers are zero. Shouldn't r0-r4 contain some addresses, memory data and a counter ? -The CPU shouldn't zero those registers when a HardFault or double-fault occurs, right ? So I wonder if the code-snippet disappeared from SRAM. Does any of this sound familiar to anyone or perhaps ring a bell ? Love Jens ------------------------------------------------------------------------------ New Year. New Location. New Benefits. New Data Center in Ashburn, VA. GigeNET is offering a free month of service with a new server in Ashburn. Choose from 2 high performing configs, both with 100TB of bandwidth. Higher redundancy.Lower latency.Increased capacity.Completely compliant. http://p.sf.net/sfu/gigenet _______________________________________________ OpenOCD-devel mailing list OpenOCD-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openocd-devel
