[STM32F429-DISC1] Use of Viper seems to crash the board

[ambimanus]

Dear community, I am quite new in the embedded world (but have several years of python experience), so bear with me if I am doing something stupidly wrong. I have a stm32f429 discovery board running MicroPython STM32F429DISC-20220618-v1.19.1 firmware. It seems the board crashes as soon as I use the viper decorator. In my actual project I am trying to make use of the display with Peter's nano-gui and pinned the problem down to the viper emitter. Here's a minimal example (which I found on the old forum):

Example here:

import uctypes

ar = bytearray(12)
ADR = uctypes.addressof(ar)

@micropython.viper
def dummy_write():
    a = ptr32(ADR)
    a[1] = 1234

print('before:', ar)
dummy_write()
print('after:', ar)

Executing this through ampy (or via mpremote mount) prints the "before" line, then returns to REPL (presumably it reboots, but I'm not sure). I get no other output (i.e., no error message or stacktrace).

Any ideas how to proceed?

Thanks in advance!

[jimmo]

Interesting! That should definitely work (and it does work for me on a STM32F405 on both 1.19.1 and the current nightly). Thanks for providing a very minimal example!

Note that using addressof isn't strictly necessary here, so I'd be interested to know if either of these work for you:

ar = bytearray(12)

@micropython.viper
def dummy_write():
    a = ptr32(ar)
    a[1] = 1234

print('before:', ar)
dummy_write()
print('after:', ar)

or

ar = bytearray(12)

@micropython.viper
def dummy_write(a: ptr32):
    a[1] = 1234

print('before:', ar)
dummy_write(ar)
print('after:', ar)

Both give me the same result as your original snippet -- but if you get different results then that might give a clue.

Also if you could try with the latest nightly build that would be helpful too. There haven't been any specific changes to the native/viper emitter that I can think of that would explain this though.

Can you link to the forum post where you got this snippet from? Was someone else seeing the same issue?

[ambimanus]

As requested, I did some tests with other firmware versions. Unfortunately, I get the very same result on every firmware beginning with 1.13 up to the latest nightly:

(MicroPython) C:\Users\CHHINRIC\Downloads\STM32F429\git\ampy>ampy run viper.py
before: bytearray(b'\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00')
MicroPython v1.19.1-600-g12f994815 on 2022-10-28; F429I-DISCO with STM32F429
Type "help()" for more information.
>>>
Aborted!

See attached viper_tests.log for the other outputs (they all look the same, except the welcome header).

Can you tell me how to debug this issue further?

(PS: I am not aware of other users with this issue. However, I am not aware of any user who successfully runs viper on this board, either.)

[rkompass]

We may compare the assembly of the function.
The following is a slightly upgraded version of a function by @dhylands

def inspect(f, nbytes=200):
    import machine
    import array
    import ubinascii
    @micropython.asm_thumb
    def dummy_asm():
        pass
    @micropython.viper
    def dummy_vip() -> int:
        return 0
    if type(f) == type(dummy_asm):
        offs = 0
    elif type(f) == type(dummy_vip):
        offs = 4
    else:
        raise ValueError('expecting an asm_thumb or viper function')
    baddr = bytes(array.array('O', [f]))
    addr = int.from_bytes(baddr, 'little')
    print('{:s} function object at: 0x{:08x}'.format(('asm_thumb' if offs == 0 else 'viper'), addr))
    print('number of args: %u' % machine.mem32[addr + offs + 4])
    code_addr = machine.mem32[addr + offs + 8]     # 8 for assembler , 12 for viper in uPy 1.19
    print('machine code at: 0x%08x' % code_addr)  # seems to fit even with viper : code begins with 'FE B5' and ends with 'FE BD'
    print('-- code --')
    for i in range(nbytes):
        print('%02x' % machine.mem8[code_addr + i], end='')
    print('\n----------')

With

ar = bytearray(12)

@micropython.viper
def dummy_write():
    a = ptr32(ar)
    a[1] = 1234

inspect(dummy_write)

on my Raspi Pico yields after taking the relevant piece of output (from the push to the pop instruction) from the disassembly by means of the
shell-storm Online-Assembler-and-Disassembler
(arm-thumb, little endian)

FE B5    push {r1, r2, r3, r4, r5, r6, r7, lr}
90 B0    sub  sp, #0x40
47 68    ldr  r7, [r0, #4]
FF 68    ldr  r7, [r7, #0xc]
7F 69    ldr  r7, [r7, #0x14]
0D 90    str  r0, [sp, #0x34]
08 46    mov  r0, r1
11 46    mov  r1, r2
1E 46    mov  r6, r3
00 29    cmp  r1, #0
00 D0    beq  #0x18
03 E0    b    #0x20
00 22    movs r2, #0
90 42    cmp  r0, r2
00 D1    bne  #0x20
04 E0    b    #0x2a
00 22    movs r2, #0
3B 46    mov  r3, r7
34 33    adds r3, #0x34
DB 6F    ldr  r3, [r3, #0x7c]
98 47    blx  r3
0D 98    ldr  r0, [sp, #0x34]
40 68    ldr  r0, [r0, #4]
40 68    ldr  r0, [r0, #4]
7B 69    ldr  r3, [r7, #0x14]
98 47    blx  r3
0E 90    str  r0, [sp, #0x38]
00 28    cmp  r0, #0
00 D1    bne  #0x3c
0F E0    b    #0x5c
00 A8    add  r0, sp, #0
3B 46    mov  r3, r7
04 33    adds r3, #4
DB 6F    ldr  r3, [r3, #0x7c]
98 47    blx  r3
00 28    cmp  r0, #0
00 D1    bne  #0x4c
07 E0    b    #0x5c
0E 98    ldr  r0, [sp, #0x38]
7B 69    ldr  r3, [r7, #0x14]
98 47    blx  r3
01 98    ldr  r0, [sp, #4]
3B 46    mov  r3, r7
0C 33    adds r3, #0xc
DB 6F    ldr  r3, [r3, #0x7c]
98 47    blx  r3
04 20    movs r0, #4
00 02    lsls r0, r0, #8
27 30    adds r0, #0x27
FB 69    ldr  r3, [r7, #0x1c]
98 47    blx  r3
07 21    movs r1, #7
FB 68    ldr  r3, [r7, #0xc]
98 47    blx  r3
04 46    mov  r4, r0
04 22    movs r2, #4
12 02    lsls r2, r2, #8
D2 32    adds r2, #0xd2
62 60    str  r2, [r4, #4]
38 68    ldr  r0, [r7]
0C 90    str  r0, [sp, #0x30]
FF E7    b    #0x7c
0E 98    ldr  r0, [sp, #0x38]
00 28    cmp  r0, #0
00 D1    bne  #0x84
05 E0    b    #0x90
7B 69    ldr  r3, [r7, #0x14]
98 47    blx  r3
3B 46    mov  r3, r7
08 33    adds r3, #8
DB 6F    ldr  r3, [r3, #0x7c]
98 47    blx  r3
0C 98    ldr  r0, [sp, #0x30]
10 B0    add  sp, #0x40
FE BD    pop  {r1, r2, r3, r4, r5, r6, r7, pc}

Trying with a pyboard 1.1 and uPy 1.17 and after adapting the offsets to 0 and 4 yields:

FE B5          push  {r1, r2, r3, r4, r5, r6, r7, lr}
94 B0          sub   sp, #0x50
C6 68          ldr   r6, [r0, #0xc]
37 68          ldr   r7, [r6]
12 90          str   r0, [sp, #0x48]
08 46          mov   r0, r1
11 46          mov   r1, r2
1E 46          mov   r6, r3
00 29          cmp   r1, #0
40 F0 04 80    bne.w #0x1e
00 22          movs  r2, #0
90 42          cmp   r0, r2
00 F0 04 80    beq.w #0x26
00 22          movs  r2, #0
D7 F8 B0 30    ldr.w r3, [r7, #0xb0]
98 47          blx   r3
12 98          ldr   r0, [sp, #0x48]
40 68          ldr   r0, [r0, #4]
7B 69          ldr   r3, [r7, #0x14]
98 47          blx   r3
13 90          str   r0, [sp, #0x4c]
00 28          cmp   r0, #0
00 F0 0E 80    beq.w #0x52
00 A8          add   r0, sp, #0
D7 F8 80 30    ldr.w r3, [r7, #0x80]
98 47          blx   r3
00 28          cmp   r0, #0
00 F0 07 80    beq.w #0x52
13 98          ldr   r0, [sp, #0x4c]
7B 69          ldr   r3, [r7, #0x14]
98 47          blx   r3
01 98          ldr   r0, [sp, #4]
D7 F8 88 30    ldr.w r3, [r7, #0x88]
98 47          blx   r3
40 F2 5E 60    movw  r0, #0x65e
FB 69          ldr   r3, [r7, #0x1c]
98 47          blx   r3
07 21          movs  r1, #7
FB 68          ldr   r3, [r7, #0xc]
98 47          blx   r3
04 46          mov   r4, r0
40 F2 D2 42    movw  r2, #0x4d2
62 60          str   r2, [r4, #4]
38 68          ldr   r0, [r7]
05 90          str   r0, [sp, #0x14]
00 F0 00 B8    b.w   #0x70
13 98          ldr   r0, [sp, #0x4c]
00 28          cmp   r0, #0
00 F0 05 80    beq.w #0x82
7B 69          ldr   r3, [r7, #0x14]
98 47          blx   r3
D7 F8 84 30    ldr.w r3, [r7, #0x84]
98 47          blx   r3
05 98          ldr   r0, [sp, #0x14]
14 B0          add   sp, #0x50
FE BD          pop   {r1, r2, r3, r4, r5, r6, r7, pc}

so we see, that viper is not the same for different processors. IIRC Raspi pico has ARM Cortex-M0+, Pyboard ARM Cortex-M4 processor.

Perhaps you have the wrong viper version working?

[jimmo]

@ambimanus Thanks for trying the different versions and scripts.

so we see, that viper is not the same for different processors. IIRC Raspi pico has ARM Cortex-M0+, Pyboard ARM Cortex-M4 processor.

Perhaps you have the wrong viper version working?

@rkompass That's right -- there are different native emitters for the different ARM families (including armv6m for the M0+, armv7m for the M4, etc) but this selection happens automatically. The common way this goes wrong is when compiling with mpy-cross with the wrong target architecture set, but in this case @ambimanus is running the .py file directly.

[dpgeorge]

I tried the original code on a Nucleo F439ZI (I don't have a F429 board). It works fine for me on latest master (it outputs bytearray(b'\x00\x00\x00\x00\xd2\x04\x00\x00\x00\x00\x00\x00') as the last line).

I think the problem is that the F429 discovery board has SDRAM which is used for the MicroPython GC heap, and the viper code is located here. The MCU is probably resetting because it doesn't allow executing code from SDRAM.

It must be exactly the same as this (very old) issue then: #4163

@ambimanus if you're able to rebuild firmware yourself, please can you try the following patches (separately, not together):

1. apply this patch and see if it works (it enables MPU on STM32F4 to allow executing from SDRAM, maybe):

diff --git a/ports/stm32/mpu.h b/ports/stm32/mpu.h
index ff51f382e..426e48a8e 100644
--- a/ports/stm32/mpu.h
+++ b/ports/stm32/mpu.h
@@ -26,7 +26,7 @@
 #ifndef MICROPY_INCLUDED_STM32_MPU_H
 #define MICROPY_INCLUDED_STM32_MPU_H
 
-#if defined(STM32F7) || defined(STM32H7) || defined(MICROPY_HW_ETH_MDC)
+#if defined(STM32F4) || defined(STM32F7) || defined(STM32H7) || defined(MICROPY_HW_ETH_MDC)
 
 #define MPU_REGION_ETH      (MPU_REGION_NUMBER0)
 #define MPU_REGION_QSPI1    (MPU_REGION_NUMBER1)
diff --git a/ports/stm32/sdram.c b/ports/stm32/sdram.c
index fb0e5a868..7df1703ea 100644
--- a/ports/stm32/sdram.c
+++ b/ports/stm32/sdram.c
@@ -244,7 +244,7 @@ static void sdram_init_seq(SDRAM_HandleTypeDef
     #define REFRESH_COUNT (MICROPY_HW_SDRAM_REFRESH_RATE * 90000 / 8192 - 20)
     HAL_SDRAM_ProgramRefreshRate(hsdram, REFRESH_COUNT);
 
-    #if defined(STM32F7) || defined(STM32H7)
+    #if defined(STM32F4) || defined(STM32F7) || defined(STM32H7)
     /* Enable MPU for the SDRAM Memory Region to allow non-aligned
        accesses (hard-fault otherwise)
        Initially disable all access for the entire SDRAM memory space,

2. just disable the heap for SDRAM:

diff --git a/ports/stm32/boards/STM32F429DISC/mpconfigboard.h b/ports/stm32/boards/STM32F429DISC/mpconfigboard.h
index 8754d3e46..1af47c73a 100644
--- a/ports/stm32/boards/STM32F429DISC/mpconfigboard.h
+++ b/ports/stm32/boards/STM32F429DISC/mpconfigboard.h
@@ -84,8 +84,10 @@
 // SDRAM
 #define MICROPY_HW_SDRAM_SIZE  (64 / 8 * 1024 * 1024)  // 64 Mbit
 #define MICROPY_HW_SDRAM_STARTUP_TEST             (1)
+#if 0
 #define MICROPY_HEAP_START  ((sdram_valid) ? sdram_start() : &_heap_start)
 #define MICROPY_HEAP_END    ((sdram_valid) ? sdram_end() : &_heap_end)
+#endif
 
 // Timing configuration for 90 Mhz (11.90ns) of SD clock frequency (180Mhz/2)
 #define MICROPY_HW_SDRAM_TIMING_TMRD        (2)

---

It's also possible the suggestion in the following comment will work, using LL_SYSCFG_EnableFMCMemorySwapping(): #4163 (comment)

But that might require changing the address of SDRAM in ports/stm32/boards/stm32f429.ld.

[ambimanus]

Thanks @rkompass and @jimmo for sharing your thoughts, this helps me learning about the internals here.

@dpgeorge I applied your patches to the latest git checkout (separately, not together) and it actually works with both variants! That's really great. Also, I ran the timing code from #4163 (comment): Disabling SDRAM heap yields a much faster execution than enabling MPU! (Remark: I did not try the LL_SYSCFG_EnableFMCMemorySwapping() approach. If you like me to do that, please advise.)

Patch 1: ports/stm32/mpu.h ports/stm32/sdram.c

(MicroPython) ampy run viper.py
before: bytearray(b'\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00')
after: bytearray(b'\x00\x00\x00\x00\xd2\x04\x00\x00\x00\x00\x00\x00')

(MicroPython) ampy run viper2.py
before: bytearray(b'\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00')
after: bytearray(b'\x00\x00\x00\x00\xd2\x04\x00\x00\x00\x00\x00\x00')

(MicroPython) ampy run viper3.py
before: bytearray(b'\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00')
after: bytearray(b'\x00\x00\x00\x00\xd2\x04\x00\x00\x00\x00\x00\x00')

(MicroPython) ampy run viper-timing.py
stack: 540 out of 15360
GC: total: 8196480, used: 2592, free: 8193888
No. of 1-blocks: 22, 2-blocks: 3, max blk sz: 40, max free sz: 511985

BC 484445
NATIVE 349073
VIPER 118822

Patch 2: ports/stm32/boards/STM32F429DISC/mpconfigboard.h

(MicroPython) ampy run viper.py
before: bytearray(b'\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00')
after: bytearray(b'\x00\x00\x00\x00\xd2\x04\x00\x00\x00\x00\x00\x00')

(MicroPython) ampy run viper2.py
before: bytearray(b'\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00')
after: bytearray(b'\x00\x00\x00\x00\xd2\x04\x00\x00\x00\x00\x00\x00')

(MicroPython) ampy run viper3.py
before: bytearray(b'\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00')
after: bytearray(b'\x00\x00\x00\x00\xd2\x04\x00\x00\x00\x00\x00\x00')

(MicroPython) ampy run viper-timing.py
stack: 532 out of 15360
GC: total: 167040, used: 2592, free: 164448
No. of 1-blocks: 22, 2-blocks: 3, max blk sz: 40, max free sz: 10145

BC 348993
NATIVE 184006
VIPER 23830

As I don't understand the implications of either modification for actual projects, could you probably elaborate on that? Ideally, you might also have a recommendation as how to proceed.