cortex m7 inline assembly - solved

[brave-ulysses]

tldr:

low scope probe impedance caused mis-identification of high speed waveform

figured out by robert-hh

hello,

trying to toggle pin B4. the functions tpth and tmch work (verified on oscope). tasm does generate some pulses, but not close to what i'd expect. any ideas?

>>> sys.implementation
(name='micropython', version=(1, 19, 1), _machine='NUCLEO-F746ZG with STM32F746', _mpy=7430)
>>> 
paste mode; Ctrl-C to cancel, Ctrl-D to finish
=== B4=pyb.Pin(pyb.Pin.cpu.B4,mode=pyb.Pin.OUT_PP)
=== 
=== @micropython.viper
=== def tpth():
===    while True:
===       B4(0)
===       B4(1)
=== 
=== @micropython.viper
=== def tmch():     
===    while True:
===       machine.mem32[stm.GPIOB+stm.GPIO_BSRR] = 1<<4
===       machine.mem32[stm.GPIOB+stm.GPIO_BSRR] = 1<<20
=== 
=== @micropython.asm_thumb
=== def tasm():                        
===     movwt(r0, stm.GPIOB)                # Use GPIOB
===     movwt(r1, 1<<4)                     # r2 has mask for setting pin 4
===     movwt(r2, 1<<(4+16))                # r3 has mask for resetting pin 4
=== 
===     label(loop)                         # loop
===     str(r1, [r0,stm.GPIO_BSRR])         # set high
===     str(r2, [r0,stm.GPIO_BSRR])         # set low
===     b(loop)
=== 
=== 
=== 
>>> 

tpth and tmch look like this:

tasm look like this:

[peterhinch]

This does not look like a logic signal: the negative excursions make no sense. I suspect you are looking at an unused pin which is capacitively coupled to a pin with a squarewave.

[brave-ulysses]

hi peter - agree, it does not look like a logic signal. the same pin (B4) is used for all scope captures. i believe something is going wrong in the tasm function. not sure how to troubleshoot it. i have tried it on another board with the same results

the procedure:
paste in the code with crtl-e / ctrl-d
run tmch()
observe scope
break out with ctrl-c
run tasm()
observe scope

my guess is that i'm not getting the transfer i intend with the str command
https://docs.micropython.org/en/v1.9.3/pyboard/reference/asm_thumb2_str.html

>>> stm.GPIOB
1073873920
>>> stm.GPIO_BSRR
24
>>> 

[brave-ulysses]

well, some progress...i can set/reset B4 via inline assembly. still have the issue with unexplained output on the pin when the same code is put in a loop

i'm wide open for suggestions

this does not work

b_set = const(stm.GPIOB)
b_clr = const(stm.GPIOB+2)
B4=pyb.Pin(pyb.Pin.cpu.B4,mode=pyb.Pin.OUT_PP)
@micropython.asm_thumb
def t_asm():                        
    label(loop)
    movwt(r0, b_set)                    # Use GPIOB
    mov(r2, 1<<4)       
    strh(r2, [r0,stm.GPIO_BSRR])            # set low
    movwt(r0, b_clr)                    # Use GPIOB
    mov(r2, 1<<4)       
    strh(r2, [r0,stm.GPIO_BSRR])            # set low
    b(loop)
t_asm()

this works

b_set = const(stm.GPIOB)
b_clr = const(stm.GPIOB+2)
B4=pyb.Pin(pyb.Pin.cpu.B4,mode=pyb.Pin.OUT_PP)
@micropython.asm_thumb
def s_asm():                        
    movwt(r0, b_set)                    # Use GPIOB
    mov(r2, 1<<4)       
    strh(r2, [r0,stm.GPIO_BSRR])            # set low
@micropython.asm_thumb
def r_asm():                        
    movwt(r0, b_clr)                    # Use GPIOB
    mov(r2, 1<<4)       
    strh(r2, [r0,stm.GPIO_BSRR])            # set low
while True:
   t=s_asm(); t=r_asm()

[peterhinch]

On the face of it, that's inexplicable. The only way that differs from the Thumb assembler I've written is its use of constants. I've always passed values as args, or put them in an array and passed the array address.

Maybe there's an asm bug involving constants in loops. I'd try passing the various stm.X values as args.

[robert-hh]

You could try to add a few NOP()'s after each write to the GPIO register. I recall some problems when writing the SSD1963 driver, partially in assembler code, that I had to add a delay between two statements setting an output high and low. Otherwise it would not change. The IO bus runs at a slower clock than the CPU. So something like:
@micropython.asm_thumb

def tasm():                        
    movwt(r0, stm.GPIOB)                # Use GPIOB
    movwt(r1, 1<<4)                     # r2 has mask for setting pin 4
    movwt(r2, 1<<(4+16))                # r3 has mask for resetting pin 4

    label(loop)                         # loop
    str(r1, [r0,stm.GPIO_BSRR])         # set high
    nop()
    nop()
    str(r2, [r0,stm.GPIO_BSRR])         # set low
    nop()
    nop()
    b(loop)

[brave-ulysses]

hi peter and robert

same results with passing in stm.GPIOB in r0 and with robert's nop() code above

@micropython.asm_thumb
def tasm(r0):                        
    movwt(r2, 1<<4)                     # r2 has mask for setting pin 4
    movwt(r3, 1<<(4+16))                # r3 has mask for resetting pin 4
    label(loop)                         # loop
    str(r2, [r0,stm.GPIO_BSRR])         # set high
    str(r3, [r0,stm.GPIO_BSRR])         # set low
    b(loop)
tasm(stm.GPIOB)

would be interesting if someone else can replicate this

thanks, guys

[robert-hh]

So I hacked together a short piece of code form what I found on my PC for PyBoard:

WR     = const(0x01)  ## Y11

from machine import Pin

wr=Pin("Y11", Pin.OUT)


@micropython.viper
def togglev():
    gpiob = ptr16(stm.GPIOB + stm.GPIO_BSRR)
    while True:
        gpiob[0] = 1 << WR
        gpiob[1] = 1 << WR


@micropython.asm_thumb
def togglea():
# set up pointers to GPIO
# r5: bit mask for control lines
# r7: GPIOB BSSRL register ptr
    movwt(r7, stm.GPIOB)
    add (r7, stm.GPIO_BSRR)
    movw(r5, WR)
#inline subroutine
    label(loop)
    strh(r5, [r7, 2])  # WR low
    strh(r5, [r7, 0])  # WR high
    bl(loop)

I get the following timings (some ringing on the wire, since I just used the long tip):
Viper:

Assembler:

[brave-ulysses]

thanks, robert!

this works as expected on my end with stm32f407. not a great square wave...tried poking the ospeedr register

maybe an stm32f7 issue? same behaviour on f756 and f746. i'll try an f767

>>> 
paste mode; Ctrl-C to cancel, Ctrl-D to finish
=== sys.implementation
=== b_set = const(stm.GPIOA)
=== b_clr = const(stm.GPIOA+2)
=== @micropython.asm_thumb
=== def t_asm():                        
===     label(loop)
===     movwt(r0, b_set)                    # Use GPIOB
===     mov(r2, 1<<4)       
===     strh(r2, [r0,stm.GPIO_BSRR])            # set low
===     movwt(r0, b_clr)                    # Use GPIOB
===     mov(r2, 1<<4)       
===     strh(r2, [r0,stm.GPIO_BSRR])            # set low
===     b(loop)
=== 
=== 
=== 
(name='micropython', version=(1, 19, 1), _machine='F4DISC with STM32F407', _mpy=7430)
>>> t_asm()

[robert-hh]

Use the 10:1 mode of your probe for a higher bandwidth, if available.

[brave-ulysses]

same behaviour on f767

f407 waveform much better with x10. thanks!

[brave-ulysses]

this code that previously was not working is now working on F756 board. main.py was removed. boot.py:

cat /flash/boot.py
import machine
import pyb
pyb.country('US') # ISO 3166-1 Alpha-2 code, eg US, GB, DE, AU
pyb.usb_mode('VCP')
reset=pyb.hard_reset

can't explain what has happened...

peter and robert, thanks for helping

previously not working:

b_set = const(stm.GPIOB)
b_clr = const(stm.GPIOB+2)
B4=pyb.Pin(pyb.Pin.cpu.B4,mode=pyb.Pin.OUT_PP)
@micropython.asm_thumb
def t_asm():                        
    label(loop)
    movwt(r0, b_set)                    # Use GPIOB
    mov(r2, 1<<4)       
    strh(r2, [r0,stm.GPIO_BSRR])            # set low
    movwt(r0, b_clr)                    # Use GPIOB
    mov(r2, 1<<4)       
    strh(r2, [r0,stm.GPIO_BSRR])            # set low
    b(loop)
t_asm()

fast toggle. 100Mhz+:

import sys
sys.implementation
b_set = const(stm.GPIOB)
b_clr = const(stm.GPIOB+2)
B4=pyb.Pin(pyb.Pin.cpu.B4,mode=pyb.Pin.OUT_PP)
machine.mem32[stm.GPIOB+stm.GPIO_OSPEEDR] = 0b11 << (4*2)
@micropython.asm_thumb
def t_asm():                        
    movwt(r0, b_set)                    # Use GPIOB
    movwt(r1, b_clr)                    # Use GPIOB
    mov(r2, 1<<4)       
    label(loop)
    strh(r2, [r0,stm.GPIO_BSRR])            # set low
    strh(r2, [r1,stm.GPIO_BSRR])            # set low
    b(loop)
t_asm()

[robert-hh]

Maybe the output speed was missing. Or you did not see it because the probe was set to x1 mode with low bandwidth, giving an Vcc/2 level, and only during the systick interrupt every ms there was time to get to 0 of 3.3V.

[brave-ulysses]

ding.ding.ding. we have a winner

moved probe back to 1x and i get the unexpected waveform. i understand the RC filter formed by the probe, but i don't follow how the systick interrupt plays into it. the spikes are every 1ms

thank you for looking at this. this was the best i could find for a genuflect emoticon

[robert-hh]

When the systick interrupt executes, the t_asm() function stops, and the GPIO output stays at the value it is at that moment. Since the systick execution time is about 300ns (see the your screenshot above), the voltage at the O-scope input can settle to the GPIO output value.

Edit: This means: the code worked all the time.
P.S.: Whenever the signal is strong enough, I use the x10 probe setting. Lower load for the tested object, better protection of the o-scope.

[peterhinch]

YES. Always use x10 unless the signal is too small to see properly.