Use U-boot to change a bit in NAND flash memory - u-boot

I am trying to test the ECC (error correction code) in U-boot. To do so, I want to use U-boot to flip a bit in NAND flash without rewriting the CRC. Then, when I restart the processor, I hope to see U-boot correct the bit using ECC.
The question is how can I write a new bit or byte or page into memory using U-boot without writing a new CRC?

Never found a u-boot with the bitterr implementation, the source code usually looks like this:
if (strcmp(cmd, "biterr") == 0) {
/* todo */
return 1;
}
In this case, the way to go is little more complicate. As it took me some time to discover how to do it, I believe it may be helpful for other to have the manual process described here.
nand read ${ram_addr1} ${sector_addr} ${sector_size}
nand read.oob ${ram_addr2} ${sector_addr} ${oob_size}
nand erase ${sector_addr} ${sector_size}
nand write ${ram_addr1} ${sector_addr_plus_page_size} ${sector_size_minus_page_size}
cp ${ram_addr2} ${ram_addr1} ${oob_size}
mm ${ram_addr1_plus_biterr_offset}
#modify a single bit of the referred data
nand write.raw ${ram_addr1} ${sector_addr} 1
Check if you get a bitflip err message:
nand read ${ram_addr1} ${sector_addr} ${sector_size}
Note that you may set the environment to run this command as is, or replace the ${} directives for the raw values. ram_addr1 and ram_addr2 may be any available ram adrress as long as ram_addr2 - ram_addr1 > sector_size

Use nand biterr to simulate a bit flipping at an offset.
For example, bit 3 in byte 69 [0x45] in the 2nd block = 0x20000
U-Boot> nand biterr 0x20045 3
Erasing at 0x20000 -- 100% complete.
toggling bit 3 in byte 45 in block 20000 00 ->08
byte offset 0x00020045 toggled bit 3
Reference:
http://www.infopoort.nl/index.php/Software:U-Boot

You can use nand read.raw and nand write.raw which by passes the writing to the OOB.

To simplify #Jonatan-Goebel answer, you can avoid a lot of the steps as long as you only clear bits, as this won't require erasing the nand.
=> setenv ram_addr1 $loadaddr
=> setenv page_addr 0
=> setenv page_size 1000
# Make sure there is actually something in nand
=> nand erase.chip && mw.b $loadaddr ff 40000 && load mmc 0 $loadaddr MLO && nand write.i $loadaddr $page_addr $filesize
# Read one raw page
=> nand read.raw ${ram_addr1} ${page_addr} 1
# Clear x number of bits
=> mm $ram_addr1
83000000: 00000040 ?
...
83000018: 4e495454 ?
8300001c: 00005347 ?
83000020: ffffffff ? efffffff
83000024: ffffffff ? => <INTERRUPT>
# Write back page
=> nand write.raw ${ram_addr1} ${page_addr} 1
# Read the page
=> nand read ${ram_addr1} ${page_addr} ${page_size}
NAND read: device 0 offset 0x0, size 0x40000
elm_config: 2
nand: bit-flip corrected #data=35
262144 bytes read: OK
Make sure you try again with too many bitflips to make sure it fails
...
=> mm $ram_addr1
...
83000020: cccccccc ? 8ccccccc
83000024: ffffffff ? => <INTERRUPT>
=> nand write.raw ${ram_addr1} ${page_addr} 1
NAND write: 4320 bytes written: OK
=> nand read ${ram_addr1} ${page_addr} ${page_size}
NAND read: device 0 offset 0x0, size 0x40000
elm_config: 2
omap-elm: uncorrectable ECC errors
NAND read from offset 0 failed -74
0 bytes read: ERROR

Related

AVR Internal eeprom reading issue

I am using the internal EEPROM of atmega8A using avr's EEPROM library. My code looks like this
#define EEPROM_ADDR 0x0A
int main(void)
{
_delay_ms(2000);
LED_Initialize();
vBlink_Led(100, 2);
//eeprom_write_byte((uint8_t*)EEPROM_ADDR, 8);
val = eeprom_read_byte((uint8_t*)EEPROM_ADDR);
while (1);
}
when i uncomment the line eeprom_write_byte((uint8_t*)EEPROM_ADDR, 8); and then read using val = eeprom_read_byte((uint8_t*)EEPROM_ADDR);, the correct value 8 is read. But when I comment on the line and then reflash the code, the values changes to 255.
any suggestions?
note - i have unchecked the box in avrdudes for erase flash and eeprom
Normaly, when "Chip Erase" operation is performed, the EEPROM is being cleared as well.
To prevent this, you have to program (i.e. set to zero) EESAVE fuse bit, which is 3rd bit in the high fuse byte (please refer to the datasheet chapter 29.2 Fuse Bits)

How to debug TF-A on ARM Cortex-A7

I'm trying a custom image for ARM STM32MP151A on a custom board. On power up nothing happens on the tty port (while using a wrong sd-card leads to a PANIC PC error - hence the port is ok). As far as I understand in the early stages of power up sequence, the ROM code should load the FSBL from the dedicated partition. Because the boot type is "trusted" that partition is filled with the TF-A firmware:
#Opt Id Name Type IP Offset Binary
- 0x01 fsbl1-boot Binary none 0x0 tf-a-stm32mp151a-myproject-mx-trusted.stm32
- 0x03 ssbl-boot Binary none 0x0 u-boot-stm32mp151a-myproject-mx-trusted.stm32
P 0x04 fsbl1 Binary mmc0 0x00004400 tf-a-stm32mp151a-myproject-mx-trusted.stm32
P 0x05 fsbl2 Binary mmc0 0x00044400 tf-a-stm32mp151a-myproject-mx-trusted.stm32
P 0x06 ssbl Binary mmc0 0x00084400 u-boot-stm32mp151a-myproject-mx-trusted.stm32
P 0x21 bootfs System mmc0 0x00284400 st-image-bootfs-openstlinux-eglfs-stm32mp1-myproject.ext4
P 0x22 vendorfs FileSystem mmc0 0x04284400 st-image-vendorfs-openstlinux-eglfs-stm32mp1-myproject.ext4
P 0x23 rootfs FileSystem mmc0 0x05284400 myproject-image-openstlinux-eglfs-stm32mp1-myproject.ext4
P 0x24 userfs FileSystem mmc0 0x4E664400 st-image-userfs-openstlinux-eglfs-stm32mp1-myproject.ext4
The question is: how to debug the very first stages of the boot sequence of an ARM-A7 if there's no output on the tty console port?

C: Reading 128 bit value from flash address

I want to read a specific 128 bit value in memory that equals the following:
128 bit val = 0171EC07F2E6C383FFFFFFFFFFFFFFFF
This id is visible when flashing a binary
Read Intel HEX application image with 608 bytes.
Received autobaud response:
Product ID: xxxxxx
Revision: xxx
Serial number: 0171EC07F2E6C383FFFFFFFFFFFFFFFF
User code present.
User code checksum failed.
Write protection disabled.
Read protection disabled.
Download completed.
Run command sent.
Programming flash image.
Read Intel HEX flash image with 189248 bytes.
Autobaud succeeded.
Flash completed.
This is the code I am using to read that address
uint8_t *address = (uint8_t *)0x34576;
uint8_t reg[16] = {0};
for (int i = 0; i < 16; i++) {
reg[i] = *address;
printf("reg[%d]= 0x%x\r\n", i, reg[i]);
*address++;
}
This is the output I'm getting:
reg[0]= 0x10
reg[1]= 0x17
reg[2]= 0xce
reg[3]= 0x70
reg[4]= 0x2f
reg[5]= 0x6e
reg[6]= 0x3c
reg[7]= 0x38
reg[8]= 0xff
reg[9]= 0xff
reg[10]= 0xff
reg[11]= 0xff
reg[12]= 0xff
reg[13]= 0xff
reg[14]= 0xff
reg[15]= 0xff
As can be seen from the output the byte order is mixed up. Is this because of little/big endian. How do I convert the value to be equal to 128 bit val

Issue with J-Link debugger while working with bootloader on STM32F765

I'm using the J-Link EDU and STLink debugger present on the Nucleo boards from ST. For testing, the bootloader code is present at 0x8000000 and just jumps to 0x8020000 where the main app code is present. When I use the Jlink EDU, it can't program the flash at 0x8020000 every time successfully and if I modify the program and start debugging, the Jlink erases the flash but does not program it successfully and after the bootloader makes the jump, the MCU gets HardFault. Now this happens whether I use Jlink or the STLINK (converted to Jlink). Usually I see it stuck at 0xFFFFFFFE. At that point the JLINK has erased the app code but failed to program it.
The interesting thing is that the STlink debugger when converted back and used with openocd has no issues whatsoever with the bootloader jumping to main app code and debugging from there.
I also find that if I program the main app code at 0x8020000 by STLink and OpenOCD and then switch to JLINK EDU for debug, it works as long as the JLINK does't reprogram it. If in the log, I see that the JLINK flashes the code, then the ST crashes after jumping from bootloader. So I definitely think it has something to do with how the JLINK is erasing and programming the ST during debug.
I also tried programming with JLINK commander and that seems to fail as well. Unless I fully erase the chip.
I'm using System Workbench 2.0 with GNU ARM Eclipse plugin for Jlink debugging with the latest ARM toolchain as of this date and Jlink 616c. I'm using the STM32F765VI with the flash in dual bank configuration.
I'm also attaching the GDB logs from JLINK and STLINK for clarity. I would like to use JLINK for debugging since I can have SWO console in eclipse whereas its very cumbersome in OpenOCD so would like to resolve it.
Failed JLINK debug after it tried to program:
SEGGER J-Link GDB Server V6.16c Command Line Version
JLinkARM.dll V6.16c (DLL compiled Jun 16 2017 18:14:49)
WARNING: Unknown command line parameter -timeout found.
WARNING: Unknown command line parameter 0 found.
-----GDB Server start settings-----
GDBInit file: none
GDB Server Listening port: 2331
SWO raw output listening port: 2332
Terminal I/O port: 2333
Accept remote connection: localhost only
Generate logfile: off
Verify download: on
Init regs on start: on
Silent mode: off
Single run mode: on
Target connection timeout: 0 ms
------J-Link related settings------
J-Link Host interface: USB
J-Link script: none
J-Link settings file: none
------Target related settings------
Target device: STM32F765VI
Target interface: SWD
Target interface speed: 1000kHz
Target endian: little
Connecting to J-Link...
J-Link is connected.
Firmware: J-Link V10 compiled Jun 16 2017 16:15:19
Hardware: V10.10
S/N: 260101191
OEM: SEGGER-EDU
Feature(s): FlashBP, GDB
Checking target voltage...
Target voltage: 3.35 V
Listening on TCP/IP port 2331
Connecting to target...Connected to target
Waiting for GDB connection...Connected to 127.0.0.1
Reading all registers
Read 4 bytes # address 0x00000000 (Data = 0x51E9FF66)
Read 2 bytes # address 0x00000000 (Data = 0xFF66)
Target interface speed set to 1000 kHz
Resetting target
Halting target CPU...
...Target halted (PC = 0x080023CC)
R0 = 00000000, R1 = 00000000, R2 = 00000000, R3 = 00000000
R4 = 00000000, R5 = 00000000, R6 = 00000000, R7 = 00000000
R8 = 00000000, R9 = 00000000, R10= 00000000, R11= 00000000
R12= 00000000, R13= 20080000, MSP= 20080000, PSP= 00000000
R14(LR) = FFFFFFFF, R15(PC) = 080023CC
XPSR 01000000, APSR 00000000, EPSR 01000000, IPSR 00000000
CFBP 00000000, CONTROL 00, FAULTMASK 00, BASEPRI 00, PRIMASK 00
Reading all registers
Read 4 bytes # address 0x080023CC (Data = 0xD034F8DF)
Read 2 bytes # address 0x080023CC (Data = 0xF8DF)
Target interface speed set to 15000 kHz
Flash breakpoints enabled
SWO disabled succesfully.
SWO enabled succesfully.
Read 4 bytes # address 0x080023CC (Data = 0xD034F8DF)
Read 2 bytes # address 0x080023CC (Data = 0xF8DF)
Downloading 520 bytes # address 0x08020000 - Verified OK
Downloading 16064 bytes # address 0x08020210 - Verified OK
Downloading 16096 bytes # address 0x080240D0 - Verified OK
Downloading 16048 bytes # address 0x08027FB0 - Verified OK
Downloading 16112 bytes # address 0x0802BE60 - Verified OK
Downloading 16096 bytes # address 0x0802FD50 - Verified OK
Downloading 16112 bytes # address 0x08033C30 - Verified OK
Downloading 16144 bytes # address 0x08037B20 - Verified OK
Downloading 16000 bytes # address 0x0803BA30 - Verified OK
Downloading 15920 bytes # address 0x0803F8B0 - Verified OK
Downloading 16176 bytes # address 0x080436E0 - Verified OK
Downloading 16064 bytes # address 0x08047610 - Verified OK
Downloading 16032 bytes # address 0x0804B4D0 - Verified OK
Downloading 15696 bytes # address 0x0804F370 - Verified OK
Downloading 16032 bytes # address 0x080530C0 - Verified OK
Downloading 16176 bytes # address 0x08056F60 - Verified OK
Downloading 16064 bytes # address 0x0805AE90 - Verified OK
Downloading 16064 bytes # address 0x0805ED50 - Verified OK
Downloading 16128 bytes # address 0x08062C10 - Verified OK
Downloading 16176 bytes # address 0x08066B10 - Verified OK
Downloading 16112 bytes # address 0x0806AA40 - Verified OK
Downloading 16304 bytes # address 0x0806E930 - Verified OK
Downloading 16272 bytes # address 0x080728E0 - Verified OK
Downloading 16048 bytes # address 0x08076870 - Verified OK
Downloading 16080 bytes # address 0x0807A720 - Verified OK
Downloading 16048 bytes # address 0x0807E5F0 - Verified OK
Downloading 16048 bytes # address 0x080824A0 - Verified OK
Downloading 14616 bytes # address 0x08086350 - Verified OK
Downloading 16144 bytes # address 0x08089C80 - Verified OK
Downloading 16224 bytes # address 0x0808DB90 - Verified OK
Downloading 16128 bytes # address 0x08091AF0 - Verified OK
Downloading 16288 bytes # address 0x080959F0 - Verified OK
Downloading 16272 bytes # address 0x08099990 - Verified OK
Downloading 16256 bytes # address 0x0809D920 - Verified OK
Downloading 14880 bytes # address 0x080A18A0 - Verified OK
Downloading 8 bytes # address 0x080A52C0 - Verified OK
Downloading 4 bytes # address 0x080A52C8 - Verified OK
Downloading 4 bytes # address 0x080A52CC - Verified OK
Downloading 1068 bytes # address 0x080A52D0 - Verified OK
Comparing flash [....................] Done.
Erasing flash [....................] Done.
Programming flash [....................] Done.
Verifying flash [....................] Done.
Writing register (PC = 0x08083ED0)
Read 4 bytes # address 0x08083ED0 (Data = 0xE0032100)
Read 2 bytes # address 0x08083ED0 (Data = 0x2100)
Read 2 bytes # address 0x0807BAAE (Data = 0xF44F)
Read 2 bytes # address 0x0807BAAE (Data = 0xF44F)
Read 2 bytes # address 0x0807BAFA (Data = 0xF44F)
Read 2 bytes # address 0x0807BAFA (Data = 0xF44F)
Read 2 bytes # address 0x08080814 (Data = 0x4B14)
Read 4 bytes # address 0x08080868 (Data = 0x2002B994)
Read 2 bytes # address 0x08080814 (Data = 0x4B14)
Read 2 bytes # address 0x0807BB44 (Data = 0x687B)
Read 2 bytes # address 0x0807BBB2 (Data = 0xF897)
Resetting target
Halting target CPU...
...Target halted (PC = 0x080023CC)
Read 2 bytes # address 0x08080814 (Data = 0x4B14)
Read 4 bytes # address 0x08080868 (Data = 0x2002B994)
Read 2 bytes # address 0x08080814 (Data = 0x4B14)
Read 4 bytes # address 0x08080868 (Data = 0x2002B994)
Read 2 bytes # address 0x08080814 (Data = 0x4B14)
R0 = 00000000, R1 = 00000000, R2 = 00000000, R3 = 00000000
R4 = 00000000, R5 = 00000000, R6 = 00000000, R7 = 00000000
R8 = 00000000, R9 = 00000000, R10= 00000000, R11= 00000000
R12= 00000000, R13= 20080000, MSP= 20080000, PSP= 00000000
R14(LR) = FFFFFFFF, R15(PC) = 080023CC
XPSR 01000000, APSR 00000000, EPSR 01000000, IPSR 00000000
CFBP 00000000, CONTROL 00, FAULTMASK 00, BASEPRI 00, PRIMASK 00
Reading all registers
Read 4 bytes # address 0x080023CC (Data = 0xD034F8DF)
Read 2 bytes # address 0x080023CC (Data = 0xF8DF)
Setting breakpoint # address 0x0807BAAE, Size = 2, BPHandle = 0x0001
Setting breakpoint # address 0x0807BAFA, Size = 2, BPHandle = 0x0002
Setting breakpoint # address 0x0807BBB2, Size = 2, BPHandle = 0x0003
Setting breakpoint # address 0x08080814, Size = 2, BPHandle = 0x0004
Starting target CPU...
...Target halted (DBGRQ, PC = 0xFFFFFFFE)
Reading all registers
WARNING: Failed to read memory # address 0xFFFFFFFE
Removing breakpoint # address 0x0807BAAE, Size = 2
Removing breakpoint # address 0x0807BAFA, Size = 2
Removing breakpoint # address 0x0807BBB2, Size = 2
Removing breakpoint # address 0x08080814, Size = 2
WARNING: Failed to read memory # address 0xFFFFFFF4
Reading 64 bytes # address 0xFFFFFFC0
WARNING: Failed to read memory # address 0xFFFFFFC0
WARNING: Failed to read memory # address 0xFFFFFFF0
Reading 64 bytes # address 0xFFFFFFC0
WARNING: Failed to read memory # address 0xFFFFFFC0
WARNING: Failed to read memory # address 0xFFFFFFF0
Successful JLINK debug if it doesn't flash:
SEGGER J-Link GDB Server V6.16c Command Line Version
JLinkARM.dll V6.16c (DLL compiled Jun 16 2017 18:14:49)
WARNING: Unknown command line parameter -timeout found.
WARNING: Unknown command line parameter 0 found.
-----GDB Server start settings-----
GDBInit file: none
GDB Server Listening port: 2331
SWO raw output listening port: 2332
Terminal I/O port: 2333
Accept remote connection: localhost only
Generate logfile: off
Verify download: on
Init regs on start: on
Silent mode: off
Single run mode: on
Target connection timeout: 0 ms
------J-Link related settings------
J-Link Host interface: USB
J-Link script: none
J-Link settings file: none
------Target related settings------
Target device: STM32F765VI
Target interface: SWD
Target interface speed: 1000kHz
Target endian: little
Connecting to J-Link...
J-Link is connected.
Firmware: J-Link V10 compiled Jun 16 2017 16:15:19
Hardware: V10.10
S/N: 260101191
OEM: SEGGER-EDU
Feature(s): FlashBP, GDB
Checking target voltage...
Target voltage: 3.35 V
Listening on TCP/IP port 2331
Connecting to target...Connected to target
Waiting for GDB connection...Connected to 127.0.0.1
Reading all registers
Read 4 bytes # address 0x00000000 (Data = 0x51E9FF66)
Read 2 bytes # address 0x00000000 (Data = 0xFF66)
Target interface speed set to 1000 kHz
Resetting target
Halting target CPU...
...Target halted (PC = 0x080023CC)
R0 = 00000000, R1 = 00000000, R2 = 00000000, R3 = 00000000
R4 = 00000000, R5 = 00000000, R6 = 00000000, R7 = 00000000
R8 = 00000000, R9 = 00000000, R10= 00000000, R11= 00000000
R12= 00000000, R13= 20080000, MSP= 20080000, PSP= 00000000
R14(LR) = FFFFFFFF, R15(PC) = 080023CC
XPSR 01000000, APSR 00000000, EPSR 01000000, IPSR 00000000
CFBP 00000000, CONTROL 00, FAULTMASK 00, BASEPRI 00, PRIMASK 00
Reading all registers
Read 4 bytes # address 0x080023CC (Data = 0xD034F8DF)
Read 2 bytes # address 0x080023CC (Data = 0xF8DF)
Target interface speed set to 15000 kHz
Flash breakpoints enabled
SWO disabled succesfully.
SWO enabled succesfully.
Read 4 bytes # address 0x080023CC (Data = 0xD034F8DF)
Read 2 bytes # address 0x080023CC (Data = 0xF8DF)
Downloading 520 bytes # address 0x08020000 - Verified OK
Downloading 16064 bytes # address 0x08020210 - Verified OK
Downloading 16096 bytes # address 0x080240D0 - Verified OK
Downloading 16048 bytes # address 0x08027FB0 - Verified OK
Downloading 16112 bytes # address 0x0802BE60 - Verified OK
Downloading 16096 bytes # address 0x0802FD50 - Verified OK
Downloading 16112 bytes # address 0x08033C30 - Verified OK
Downloading 16144 bytes # address 0x08037B20 - Verified OK
Downloading 16000 bytes # address 0x0803BA30 - Verified OK
Downloading 15920 bytes # address 0x0803F8B0 - Verified OK
Downloading 16176 bytes # address 0x080436E0 - Verified OK
Downloading 16064 bytes # address 0x08047610 - Verified OK
Downloading 16032 bytes # address 0x0804B4D0 - Verified OK
Downloading 15696 bytes # address 0x0804F370 - Verified OK
Downloading 16032 bytes # address 0x080530C0 - Verified OK
Downloading 16176 bytes # address 0x08056F60 - Verified OK
Downloading 16064 bytes # address 0x0805AE90 - Verified OK
Downloading 16064 bytes # address 0x0805ED50 - Verified OK
Downloading 16128 bytes # address 0x08062C10 - Verified OK
Downloading 16176 bytes # address 0x08066B10 - Verified OK
Downloading 16112 bytes # address 0x0806AA40 - Verified OK
Downloading 16304 bytes # address 0x0806E930 - Verified OK
Downloading 16272 bytes # address 0x080728E0 - Verified OK
Downloading 16048 bytes # address 0x08076870 - Verified OK
Downloading 16080 bytes # address 0x0807A720 - Verified OK
Downloading 16048 bytes # address 0x0807E5F0 - Verified OK
Downloading 16048 bytes # address 0x080824A0 - Verified OK
Downloading 14616 bytes # address 0x08086350 - Verified OK
Downloading 16144 bytes # address 0x08089C80 - Verified OK
Downloading 16224 bytes # address 0x0808DB90 - Verified OK
Downloading 16128 bytes # address 0x08091AF0 - Verified OK
Downloading 16288 bytes # address 0x080959F0 - Verified OK
Downloading 16272 bytes # address 0x08099990 - Verified OK
Downloading 16256 bytes # address 0x0809D920 - Verified OK
Downloading 14880 bytes # address 0x080A18A0 - Verified OK
Downloading 8 bytes # address 0x080A52C0 - Verified OK
Downloading 4 bytes # address 0x080A52C8 - Verified OK
Downloading 4 bytes # address 0x080A52CC - Verified OK
Downloading 1068 bytes # address 0x080A52D0 - Verified OK
Comparing flash [....................] Done.
Verifying flash [....................] Done.
Writing register (PC = 0x08083ED0)
Read 4 bytes # address 0x08083ED0 (Data = 0xD034F8DF)
Read 2 bytes # address 0x08083ED0 (Data = 0xF8DF)
Read 2 bytes # address 0x08083ED2 (Data = 0xD034)
Read 2 bytes # address 0x0807BAAE (Data = 0xF44F)
Read 2 bytes # address 0x0807BAAE (Data = 0xF44F)
Read 2 bytes # address 0x0807BB44 (Data = 0x687B)
Read 2 bytes # address 0x0807BBB2 (Data = 0xF897)
Read 2 bytes # address 0x0807BAFA (Data = 0xF44F)
Read 2 bytes # address 0x0807BAFA (Data = 0xF44F)
Resetting target
Halting target CPU...
...Target halted (PC = 0x080023CC)
Read 2 bytes # address 0x08080814 (Data = 0x4B15)
Read 4 bytes # address 0x0808086C (Data = 0x2002B994)
Read 2 bytes # address 0x08080814 (Data = 0x4B15)
Read 4 bytes # address 0x0808086C (Data = 0x2002B994)
Read 2 bytes # address 0x08080814 (Data = 0x4B15)
R0 = 00000000, R1 = 00000000, R2 = 00000000, R3 = 00000000
R4 = 00000000, R5 = 00000000, R6 = 00000000, R7 = 00000000
R8 = 00000000, R9 = 00000000, R10= 00000000, R11= 00000000
R12= 00000000, R13= 20080000, MSP= 20080000, PSP= 00000000
R14(LR) = FFFFFFFF, R15(PC) = 080023CC
XPSR 01000000, APSR 00000000, EPSR 01000000, IPSR 00000000
CFBP 00000000, CONTROL 00, FAULTMASK 00, BASEPRI 00, PRIMASK 00
Reading all registers
Read 4 bytes # address 0x080023CC (Data = 0xD034F8DF)
Read 2 bytes # address 0x080023CC (Data = 0xF8DF)
Setting breakpoint # address 0x0807BAAE, Size = 2, BPHandle = 0x0001
Setting breakpoint # address 0x0807BAFA, Size = 2, BPHandle = 0x0002
Setting breakpoint # address 0x0807BBB2, Size = 2, BPHandle = 0x0003
Setting breakpoint # address 0x08080814, Size = 2, BPHandle = 0x0004
Starting target CPU...
...Breakpoint reached # address 0x08080814
Reading all registers
Read 4 bytes # address 0x08080814 (Data = 0x68184B15)
Removing breakpoint # address 0x0807BAAE, Size = 2
Removing breakpoint # address 0x0807BAFA, Size = 2
Removing breakpoint # address 0x0807BBB2, Size = 2
Removing breakpoint # address 0x08080814, Size = 2
Reading 64 bytes # address 0x20003A40
Read 4 bytes # address 0x0802ED40 (Data = 0xB083B480)
Reading 64 bytes # address 0x200039C0
Read 4 bytes # address 0x0802ED40 (Data = 0xB083B480)
STLINK success debug
Open On-Chip Debugger 0.10.0-dev-00278-ga53935e-dirty (2017-05-09-09:25)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.org/doc/doxygen/bugs.html
srst_only separate srst_nogate srst_open_drain connect_assert_srst
Info : The selected transport took over low-level target control. The results might differ compared to plain JTAG/SWD
adapter speed: 4000 kHz
adapter_nsrst_delay: 100
Info : clock speed 4000 kHz
Info : STLINK v2 JTAG v27 API v2 M v15 VID 0x0483 PID 0x374B
Info : using stlink api v2
Info : Target voltage: 0.023669
Error: target voltage may be too low for reliable debugging
Info : STM32F765VITx.cpu: hardware has 8 breakpoints, 4 watchpoints
Info : accepting 'gdb' connection on tcp/3333
STM32F765VITx.cpu: target state: halted
target halted due to debug-request, current mode: Thread
xPSR: 0x01000000 pc: 0x080023cc msp: 0x20080000
Info : flash size probed value 2048
Info : flash size probed value 2048
STM32F765VITx.cpu: target state: halted
target halted due to debug-request, current mode: Thread
xPSR: 0x01000000 pc: 0x080023cc msp: 0x20080000
STM32F765VITx.cpu: target state: halted
target halted due to debug-request, current mode: Thread
xPSR: 0x01000000 pc: 0x080023cc msp: 0x20080000
Info : Padding image section 0 with 8 bytes
Info : Padding image section 1 with 24 bytes
STM32F765VITx.cpu: target state: halted
target halted due to breakpoint, current mode: Thread
xPSR: 0x61000000 pc: 0x20000084 msp: 0x20080000
Warn : keep_alive() was not invoked in the 1000ms timelimit. GDB alive packet not sent! (4290). Workaround: increase "set remotetimeout" in GDB
STM32F765VITx.cpu: target state: halted
target halted due to debug-request, current mode: Thread
xPSR: 0x01000000 pc: 0x080023cc msp: 0x20080000
JLINK commander failed log
SEGGER J-Link Commander V6.16c (Compiled Jun 16 2017 18:15:26)
DLL version V6.16c, compiled Jun 16 2017 18:14:49
Connecting to J-Link via USB...O.K.
Firmware: J-Link V10 compiled Jun 16 2017 16:15:19
Hardware version: V10.10
S/N: 260101191
License(s): FlashBP, GDB
OEM: SEGGER-EDU
VTref = 3.348V
Type "connect" to establish a target connection, '?' for help
J-Link>connect
Please specify device / core. <Default>: STM32F765VI
Type '?' for selection dialog
Device>
Please specify target interface:
J) JTAG (Default)
S) SWD
TIF>s
Specify target interface speed [kHz]. <Default>: 4000 kHz
Speed>
Device "STM32F765VI" selected.
Connecting to target via SWD
Found SW-DP with ID 0x5BA02477
Found SW-DP with ID 0x5BA02477
Scanning APs, stopping at first AHB-AP found.
AP[0] IDR: 0x74770001 (AHB-AP)
AHB-AP ROM: 0xE00FD000 (Base addr. of first ROM table)
CPUID reg: 0x411FC270. Implementer code: 0x41 (ARM)
Found Cortex-M7 r1p0, Little endian.
FPUnit: 8 code (BP) slots and 0 literal slots
CoreSight components:
ROMTbl[0] # E00FD000
ROMTbl[0][0]: E00FE000, CID: B105100D, PID: 000BB4C8 ROM Table
ROMTbl[1] # E00FE000
ROMTbl[1][0]: E00FF000, CID: B105100D, PID: 000BB4C7 ROM Table
ROMTbl[2] # E00FF000
ROMTbl[2][0]: E000E000, CID: B105E00D, PID: 000BB00C SCS
ROMTbl[2][1]: E0001000, CID: B105E00D, PID: 000BB002 DWT
ROMTbl[2][2]: E0002000, CID: B105E00D, PID: 000BB00E FPB
ROMTbl[2][3]: E0000000, CID: B105E00D, PID: 000BB001 ITM
ROMTbl[1][1]: E0041000, CID: B105900D, PID: 001BB975 ETM-M7
ROMTbl[0][1]: E0040000, CID: B105900D, PID: 000BB9A9 TPIU-M7
Cache: Separate I- and D-cache.
I-Cache L1: 16 KB, 256 Sets, 32 Bytes/Line, 2-Way
D-Cache L1: 16 KB, 128 Sets, 32 Bytes/Line, 4-Way
Cortex-M7 identified.
J-Link>r
Reset delay: 0 ms
Reset type NORMAL: Resets core & peripherals via SYSRESETREQ & VECTRESET bit.
Setting AIRCR.SYSRESETREQ
J-Link>loadbin C:\Users\User\workspace_10\DC_Booster_F756\Debug\DC_Booster_F756.bin,0x08020000
Downloading file [C:\Users\User\workspace_10\DC_Booster_F756\Debug\DC_Booster_F756.bin]...
J-Link: Flash download: Flash programming performed for 2 ranges (131072 bytes)
J-Link: Flash download: Total time needed: 6.157s (Prepare: 0.022s, Compare: 0.081s, Erase: 4.931s, Program: 1.116s, Verify: 0.000s, Restore: 0.005s)
J-Link: Flash download: Restarting flash programming due to program error (possibly skipped erasure of half-way erased sector).
J-Link: Flash download: Skip optimizations disabled for second try.
Error while programming flash: Programming failed.
J-Link>verifybin C:\Users\User\workspace_10\DC_Booster_F756\Debug\DC_Booster_F756.bin,0x08020000
Loading binary file C:\Users\User\workspace_10\DC_Booster_F756\Debug\DC_Booster_F756.bin
Reading 546556 bytes data from target memory # 0x08020000.
Verify failed # address 0x08065522.
Expected FE read 00J-Link>
I reached over to the guys at Segger and they created a wiki page detailing how to resolve the issue. To make the Jlink aware of the Dual Bank config on STM32F7 devices, Jlink Open Flash loader must be used with custom script containing info of the Dual Bank config. Once that's done, the Jlink debugger has no problem when the program jumps from bootloader to main app. Here are the steps for getting Jlink to work with STM32F765VI operating in Dual Bank mode.
First off, use the latest version from 616f onwards
download and place the precompiled binary (ST STM32F7xxxx_2MB_DualBank.elf)from Jlink wiki to folder containing Jlink.exe and JLinkDevices.xml
edit JLinkDevices.xml to contain info related to the MCU and direct it to use the precompiled binary instead of the default one in Jlink. Add the following beneath the database tag at the start:
<!-- This entry will overwrite the existing device entry in the J-Link software, so that a custom flash algorithm is used for the internal flash -->
<Device>
<ChipInfo Vendor="ST" Name="STM32F765VI" Core="JLINK_CORE_CORTEX_M7" />
<FlashBankInfo Name="Internes Flash" BaseAddr="0x08000000" MaxSize="0x00200000 " Loader="ST_STM32F7xxxx_2MB_DualBank.elf" LoaderType="FLASH_ALGO_TYPE_OPEN" />
</Device>
If you have multiple versions of Jlink installed, make sure you're using the one which has its JLinkDevices.xml edited to use the precompiled binary in your debugging session.
According to the first log it seems to me that J-Link erases the flash and then programs it from address 0x08020000 on -> no bootloader and nothing to execute at 0x08000000 -> jumps right to hardFault (although no handler is found in the vector table and the CPU locks up). I'm not an expert of J-Link, but we use it in a similar toolchain, with the following scenarios:
the BSL and the application binaries are combined using a simple tool and flashed together by J-Link. Either one can be debugged afterwards by connecting to the running target.
BSL is excluded and substituted by a 'stub' only doing the jump to the application
Both work flawlessly.

Why u-boot always mark writed block as bad?

I'm developing an nand flash driver of u-boot. I think it works well but the environment of u-boot doesn't work properly. Here is what i have done for testing:
Erase the whole nand flash by code purely coded by myself, these codes are not related to u-boot. And no bad blocks found. (Is it possible for a nand flash to have no bad block?). Here is the code
void nand_erase(u32 addr)
{
if (addr & (BLOCK_SIZE - 1))
{
printf("not block align\n");
return;
}
u32 row = addr / 2048;
nand_select_chip();
nand_cmd(0x60);
NFADDR = row & 0xFF;
NFADDR = (row >> 8) & 0xFF;
NFADDR = (row >> 16) & 0x07;
nand_cmd(0xD0);
nand_wait_ready();
nand_cmd(0x70);
u8 status = nand_read();
if (status & 0x01)
{
printf("block 0x%x is bad", addr);
}
nand_deselect_chip();
}
Start u-boot, it prompt"bad CRC ,using default environment".
Now i use "setenv test 100" and "printenv test", it works well, and "saveenv", it prompt "OK" as well.
And i use "nand bad", it shows nothing.
Restart the board and u-boot
Now it says that "readenv() failed, using default environment".
And i "printenv test", it fails. Then i chekced "nand bad", it shows a bad block exactly at "CONFIG_ENV_OFFSET"
Then i changed CONFIG_ENV_OFFSET to another value. and repeat step 1-7. It will shows a bad block again at the new CONFIG_ENV_OFFSET.
I've checked my driver, the write operation and read operation are good i think. The steps are here:
"nand dump 0" , and it shows all 0xff
"nand write 20000000 0 800" to write memory into nand flash.
Then "nand dump 0", it shows the same values as "md 20000000 100" does.
So, you can see that after saveenv, the block at CONFIG_ENV_OFFSET will be marked as bad, I really don't know why
Now i figure out.
I set ecc.mode = NAND_ECC_HW_SYNDROME, But XXX_syndrome function doesn't maintain ecc layout. It just simply write ecc after main data. Finally it will override the first and second bytes of oob area in each page , but u-boot check these two bytes as bad block marker, so here is the answer.

Resources