Did my STM32L496 Disco arrive with broken internal settings?

[FBisk.1]

Hello,

I have recently purchased an STM32L496 Discovery Kit to play around with and get familiar with the chip. I have decided to start porting some of my OS from a different board to this board, but before I even got to that stage I ran into some issues.

When I set up the vector table for the chip at the start of the flash and have the 2nd entry be the address of a simple function running in a loop for testing, it won't even make it there. It appears no matter what I do it immediately enters the handler for the Hard Fault. That is to say, it never even jumps to the start function, so it isn't my code triggering the Hard Fault. The UFSR register is giving me an INVSTATE, but that doesn't make sense as I haven't executed any code yet.

There appear to be some other issues as well with the board:

* Using the command `st-flash write ./arm.bin 0x08000000` gives me back the error "Unknown Memory Region" as well as reporting there is no flash "INFO common.c: L496x/L4A6x: 256 KiB SRAM, 0 KiB flash in at least 2 KiB pages"

* Using the arm gdb to flash an .elf file using the load command immediately fails

* Forcing a flash using the above st-flash command in combination with the `--flash=1m` flag does work, but it ends up immediately triggering a Hard Fault as explained above.

* The st-util utility on linux reports flash sizes of 448kb, 0kb, 12338kb 65xxxkb, etc.. everytime I fire up the utility.

* The ST-LINK utility on windows does appear to be able to flash it, but the core instantly locks and gets stuck in the Hard Fault handler loop.

So my question is, is this board broken? Is there any way of saving it?

Thanks for your help

Output from st-info --probe:

 ~/STM32L4/toolchain/stm32_dev/stlink-develop/bin/st-info --probe

Unrecognized flash type

---------- old ------------

# Chip-ID file for L496x/L4A6x

#

chip_id 0x461

description L496x/L4A6x

flash_type 6

flash_pagesize 0x800

sram_size 0x40000

bootrom_base 0x1fff0000

bootrom_size 0x7000

option_base 0x1fff7800

option_size 0x4

flags 2

---------- new ------------

# Chip-ID file for L496x/L4A6x

#

chip_id 0x461

description L496x/L4A6x

flash_type 6

flash_pagesize 0x800

sram_size 0x40000

bootrom_base 0x1fff0000

bootrom_size 0x7000

option_base 0x1fff7800

option_size 0x4

flags 2

Found 1 stlink programmers

 version:  V2J37S26

 serial:   066CFF343636574D43044929

 flash:   0 (pagesize: 2048)

 sram:    262144

 chipid:   0x0461

---------- old ------------

# Chip-ID file for L496x/L4A6x

#

chip_id 0x461

description L496x/L4A6x

flash_type 6

flash_pagesize 0x800

sram_size 0x40000

bootrom_base 0x1fff0000

bootrom_size 0x7000

option_base 0x1fff7800

option_size 0x4

flags 2

---------- new ------------

# Chip-ID file for L496x/L4A6x

#

chip_id 0x461

description L496x/L4A6x

flash_type 6

flash_pagesize 0x800

sram_size 0x40000

bootrom_base 0x1fff0000

bootrom_size 0x7000

option_base 0x1fff7800

option_size 0x4

flags 2

 descr:   L496x/L4A6x

[Tesla DeLorean]

Is the address you put in the vector table odd or even?

[FBisk.1]

I'm sorry, the below was meant as a reply to you.

[FBisk.1]

It is even, 0x080001fc.

If it is of any help, a good friend of mine owns the very same board and asking him to upload the very same code to his board makes it reach the start function triggered from the vector table. Whereas my board with the exact same .bin file on it triggers a hard fault without reaching the start function.

I'm not sure what it could be that is going wrong..

[Tesla DeLorean]

Even addresses infer 32-bit ARM instructions, the Cortex-Mx can't execute those, only Thumb instructions, and will fault.

========================================================================
 
** Section #1 'ER_IROM1' (***_PROGBITS) [SHF_ALLOC + SHF_EXECINSTR]
 Size : 32288 bytes (alignment 4)
 Address: 0x08003000
 
 $d.realdata
 RESET
 __Vectors
 0x08003000: 20001f80 ... DCD 536878976
 0x08003004: 0800313d =1.. DCD 134230333
 0x08003008: 08006a99 .j.. DCD 134245017
 0x0800300c: 080031b7 .1.. DCD 134230455
 0x08003010: 08006a95 .j.. DCD 134245013
..
 Reset_Handler
 0x0800313c: 4840 @H LDR r0,[pc,#256] ; [0x8003240] = 0x20007ff0
 0x0800313e: 4941 AI LDR r1,[pc,#260] ; [0x8003244] = 0xdeadcafe
 0x08003140: 6802 .h LDR r2,[r0,#0]
 0x08003142: 6000 .` STR r0,[r0,#0]
 0x08003144: 428a .B CMP r2,r1
 0x08003146: d043 C. BEQ Reflash_System ; 0x80031d0
 0x08003148: 483f ?H LDR r0,[pc,#252] ; [0x8003248] = 0x80089b1
 0x0800314a: 4780 .G BLX r0
 0x0800314c: 483f ?H LDR r0,[pc,#252] ; [0x800324c] = 0x8003129
 0x0800314e: 4700 .G BX r0
 bang
 0x08003150: 4a3f ?J LDR r2,[pc,#252] ; [0x8003250] = 0x20002001
 0x08003152: e9d20100 .... LDRD r0,r1,[r2,#0]
 0x08003156: 4770 pG BX lr

[FBisk.1]

You are right. I appreciate the help.

Do you have any idea about the flashing problem I have? I can't flash it using gdb's load or st-flash without forcing the flash size..