[NUCLEO_F401RE] Odd problems.

[mwm]

I've been trying to get 1.9.1 to work on a NUCLEF401RE, with some success.

First, I think I've got the basics down right: my other supported STM cards (an STM32F4 Discovery and an STM32F429I Discovery) seem to work fine - at least, I get a REPL and can poke around in it. The REPL never prompts on the NUCLEO board. But they won't work for the project at hand. I do notice they use the OTG port to connect, and the NUCLEO boards don't have those. But I don't think that's the issue.

Using gdb on mp on that board doesn't turn up much useful. It gets to main, and then seem to hang in SystemClock_Config. Trying to turn off the optimization by removing "-Os -DNDEBUG" causes the binary to no longer fit, so does a DEBUG build.

I tried building them minimal port with no better luck. It does seem to hang in Default_Handler in this case, though. Except that if I turn off -Os -DNDEBUG in the Makefile, it works. Various combinations of build flags work or not. Unfortunately, the only time I got a build that failed and had debug flags, openocd wouldn't connect to the board.

I did notice that after the build doesn't get a REPL, I have to power cycle the board after it fails to flash. Power cycling before trying to flash it doesn't work, nor does doing a reset instead of a power cycle. Because of that - and the length of the day - the reports about which combinations of flags may or may not work should be taken with a grain of salt.

So, any suggestions on what to try next to get a REPL out of this board? Maybe something I can do to provide more information?

Thanks

[dhylands]

On my linux machine (ubuntu 16.04 LTS) I was able to do:

Code: Select all

make BOARD=NUCLEO_F401RE
make BOARD=NUCLEO_F401RE deploy-stlink

and I then had to press the RESET button and I got a REPL on /dev/ttyACM0:

Code: Select all

600 >usb-ser-mon.py 
USB Serial device with vendor 'STMicroelectronics' serial '0671FF575056805087031137' connected @/dev/ttyACM0
Use Control-X to exit.
MicroPython v1.9.1-216-g63edc2e-dirty on 2017-08-10; NUCLEO-F401RE with STM32F401xE
Type "help()" for more information.
>>> 
>>> 

I was using the latest git, I didn't try specifically with the 1.9.1 release.

And for what its worth, I was able to build and flash from my MacBook Pro as well.

Since the STLINK processor is being used as a USB-to-serial translator its important that your terminal program be set to use 115200 baud.

[mwm]

Yup, that's what works for my other boards. Doesn't work for the NUCLEO board. I get no response from the REPL. I just did a pull of master and rebuilt from scratch - same results..

Version info (forgot that last time)
Ubuntu 16.10
arm-none-eabi-gcc (15:4.9.3+svn231177-1) 4.9.3 20150529 (prerelease)
Python 2.7.12+ (default, Sep 17 2016, 12:08:02)
Python 3.5.2+ (default, Sep 22 2016, 12:18:14)
MicroPython v1.9.1-216-g63edc2e on 2017-08-10; F429I-DISCO with STM32F429

Googling has turned up that people have had issues with bluetooth 3, so I've tried a a BT 2 slot on my BT2 multi card reader. Others complained about needing to lower the speed, so I tried changing mpconfigboard to do that. Also tried connecting to (but not building on) a Win 10 laptop. None of that helped.

Again, I got a working build of the minimal port by by tweaking the CFLAGS settings. What I'm looking for is suggestions for things to change that might make a difference, or requests for information that might help someone make such suggestions.

[dhylands]

The other thing to do is to check all of the solder balls on the NUCLEO board to make sure that they're right.

In order for the the REPL to get back to the stlink processor, you want SB13, SB14 to be closed and you want SB61, SB62, and SB63 to be open. Note that wiring things up like this will disconnect D0/D1 on the arduino connector from the UART on the 401.

You also want SB16 and SB50 to both be closed if there is no X3 crystal on your board (this causes an 8 MHz signal from the stlink processor to be used to clock the STM32F401).

[mwm]

The solder connections all look good to me, but me eyeballing them isn't really a reliable test.

The jumpers you specified are all right. I haven't done any hardware mods to this since I got it, so that's expected.

Further, I can verify that the serial connection works as expected. A simple script on mbed to open it, spit out instructions, and then watch for incoming characters and toggle the LED works fine. For that matter, I tweaked the minimal build to use USART1 on PA2 & PA3 (the one that goes through the STLINK), and it worked fine.

So I'm pretty sure the hardware for the REPL is working properly. Possibly some other bit of hardware is busted, and that's hanging things when it fails to init. That would certainly explain the behavior I see in gdb. Is there some easy way to test intermediate states between the full build and the minimal port?

[dhylands]

PA2 and PA3 are USART2.

You could try to do a full erase of the part to ensure that the file system isn't corrupted in some weird way.

[mwm]

You're right - I changed it from USART1 to USART2, not the other way around. Sorry about that.

I erased it. In a variety of ways. I used openocd to check that it was erased before flashing. Did a clean build.
Still no luck

[mwm]

Ok, progress. Well, towards solving the problem if not the solution.

In poking at the web, I stumbled across a blog post by the original author of the port (or so I believe), who pointed out that in order to debug it, he had to change COPT from -O0 to -O1. I tried, and sure enough, I get a binary I can load and debug.

So I now know where the problem is: the clock is failing to configure. In particular, this stretch of HAL_RCC_OscConfig:

Code: Select all

      __HAL_RCC_HSE_CONFIG(RCC_OscInitStruct->HSEState);
      
      /* Check the HSE State */
      if((RCC_OscInitStruct->HSEState) != RCC_HSE_OFF)
      {
        /* Get Start Tick*/
        tickstart = HAL_GetTick();
      
        /* Wait till HSE is ready */  
        while(__HAL_RCC_GET_FLAG(RCC_FLAG_HSERDY) == RESET)
        {
          if((HAL_GetTick() - tickstart ) > HSE_TIMEOUT_VALUE)
          {
            return HAL_TIMEOUT;
          } 
        }
      }

is timing out. I just pulled the latest sources, made the indicated change to COPT, then did "make BOARD=NUCLEO_F401RE DEBUG=1" followed by "make BOARD=NUCLEO_F401RE DEBUG=1" to test.

I haven't dug into what's actually going on there yet. Any suggestions for when I get back to it?

Thanks,
Mike

[mwm]

Ok, GOT it. I double checked the clock hardware again, and sure enough, SB16 and SB50 were wrong. Closing those fixed things.

Thanks for the help.