8 years, 4 months ago.

Board bricked by writing to FLASH?

EDIT: Doesn't seem to have bricked the board, but it seems that there are a lot of issues. Firstly using flash write/read with UART is very iffy, changing baud rate to 115200 seems to break it, the baud rate is changed but whatever it's changed to is not a valid baud rate, opening the port at 115200 or 9600 on the PC gives garbled characters. I've removed the code to change the baud speed to 115200 and opened the port on the PC at 9600 and now I get the clear data out which I would expect.

Also for reasons unknown, the CMSIS interface is flakey. Right now I can't connect to it using openocd at all:

openocd -f /usr/share/openocd/scripts/interface/cmsis-dap.cfg -f /usr/share/openocd/scripts/target/stm32f4x.cfg 
Open On-Chip Debugger 0.9.0 (2015-05-19-13:50)
Licensed under GNU GPL v2
For bug reports, read
        http://openocd.org/doc/doxygen/bugs.html
Info : only one transport option; autoselect 'swd'
adapter speed: 2000 kHz
adapter_nsrst_delay: 100
none separate
cortex_m reset_config sysresetreq
Error: unable to find CMSIS-DAP device

I've removed it and reconnected it multiple times:

[ 9437.633029] sd 7:0:0:0: [sdc] 16512 512-byte logical blocks: (8.45 MB/8.06 MiB)
[ 9437.643943]  sdc:
[ 9536.520028] VFS: busy inodes on changed media or resized disk sdc
[ 9536.542036] FAT-fs (sdc): unable to read boot sector to mark fs as dirty
[ 9538.561598] sd 7:0:0:0: [sdc] 16512 512-byte logical blocks: (8.45 MB/8.06 MiB)
[ 9538.572526]  sdc:
[ 9633.836713] usb 1-10: USB disconnect, device number 8
[ 9637.820109] usb 1-10: new full-speed USB device number 9 using xhci_hcd
[ 9637.996264] usb-storage 1-10:1.0: USB Mass Storage device detected
[ 9637.996323] scsi host8: usb-storage 1-10:1.0
[ 9637.996800] cdc_acm 1-10:1.1: ttyACM0: USB ACM device
[ 9637.999555] hid-generic 0003:0D28:0204.0005: hiddev0,hidraw3: USB HID v1.00 Device [\xffffffd0\xffffff89 \xffffffd0\xffffff89] on usb-0000:00:14.0-10/input3
[ 9638.993096] scsi 8:0:0:0: Direct-Access     MBED     microcontroller  1.0  PQ: 0 ANSI: 2
[ 9638.993719] sd 8:0:0:0: [sdc] 16512 512-byte logical blocks: (8.45 MB/8.06 MiB)
[ 9638.993995] sd 8:0:0:0: [sdc] Write Protect is off
[ 9638.993996] sd 8:0:0:0: [sdc] Mode Sense: 03 00 00 00
[ 9638.994979] sd 8:0:0:0: [sdc] No Caching mode page found
[ 9638.994981] sd 8:0:0:0: [sdc] Assuming drive cache: write through
[ 9639.005986]  sdc:
[ 9639.007561] sd 8:0:0:0: [sdc] Attached SCSI removable disk

I'm attempting to write 8 bytes/64 bits of data (doubleword) using HAL_FLASH_Program(TYPEPROGRAM_DOUBLEWORD, Address, Data); - The problem is it enters this function and never returns (not sure if it crashes or enters an infinate loop since I'm unable to debug it).

After a full reboot of everything, the CMSIS interface is working again. If I run the program, the final UART output I see is just before I try to save data to the FLASH, however if I step through all the code, I get the UART output after this point, so this looks like a (timing) bug to me.

Original post:

I created a simple test program to write/read some sample data from the FLASH in sector 11 (thinking the last sector would be unused):

int main()
{
    Serial s(USBTX, USBRX);
    s.baud(115200);
    HAL_FLASH_Unlock();
    HAL_StatusTypeDef Stat1 = HAL_FLASH_Program(TYPEPROGRAM_BYTE, 0x080E0000, 0xAB);
    printf("E1 %d\r\n", Stat1);
    FLASH_ErrorTypeDef Stat2 = HAL_FLASH_GetError();
    printf("E2 %d\r\n", Stat2);
    wait(2);
    HAL_FLASH_Lock(); //Originally this was commented out, not sure if this not being called caused the issue?
    printf("Data written");

    uint32_t Address = 0x080E0000;
    char MyData;
    MyData = *(__IO uint8_t*)Address;
    printf("Got: %d", MyData);

    while(1)
    {
        wait(5);
        printf("Spin");
    }

If I try to debug using openocd using step it doesn't process the step, it just continually 'runs' something (not the code I've downloaded to it). Breakpoints don't trigger. I compiled and downloaded a simple program after this to just print out some data but nothing ever appears from the UART. I've tried redownloading the firmware in CRP_DISABLED mode but it still won't work, I therefore think this has somehow bricked the module/board, is there any way to resolve this issue?

Question relating to:

The Arch Max is an mbed enabled development board for rapid prototyping. It's based on a STM32F407VET6 microcontrolle with an ARM Cortex-M4F core running at 168MHz. It includes an open …

1 Answer

8 years, 3 months ago.

https://github.com/Seeed-Studio/Arch_Max/wiki/Get-Started-with-EmBitz-and-Seeed-Arch-Max is a guide to use openocd and arch max with emblocks ide.

or have you tried the Arch Max with pyOCD?

https://github.com/Seeed-Studio/Arch_Max/wiki/Using-pyOCD-with-Seeed-Arch-Max

is a guide to get started.