search

ilg-archived / qemu

The GNU MCU Eclipse QEMU
http://gnuarmeclipse.github.io/qemu/
Other
205 stars 78 forks source link

QEMU doesn't work with CMSIS 5 #48

Open amq opened 6 years ago

amq commented 6 years ago

Description

I could run mbed-os 5.4 (CMSIS 4) with STM32F429I-Discovery, but mbed-os 5.5 (CMSIS 5) constantly fails. Also tried STM32F4-Discovery.

Steps to Reproduce

  1. Create a project with mbed-os 5.4. You can use mine
  2. Launch it with STM32F429I-Discovery
  3. If it complains about no floating point support, change M4F to M4 in mbed-os/targets/targets.json and re-export the project
  4. Should work fine
  5. Upgrade mbed-os to 5.5 by editing mbed-os.lib and running mbed update
  6. Try launching it again
  7. STM32F429I-Discovery gives PRIGROUP unimplemented
  8. STM32F4-Discovery gives Bad ram pointer (nil)

Expected behaviour: mbed-os 5.5 should work at least as well as mbed-os 5.4

Actual behaviour: mbed-os 5.5 doesn't work

Versions

ilg-ul commented 6 years ago

thank you for your report, it might be so, I never tried CMSIS 5.

time permitting, I'll take a look.

andrewleech commented 6 years ago

I've run into the same problem (also using mbed 5.5) and tried target code level debugging to narrow the scope of the issue, without a lot of success.

The same error Bad ram pointer (nil) occurs for both M3 and M4 (NUCLEO_F103RB, STM32F429I-Discovery)

I'm on windows, same error is printed out and qemu dies with a segfault.

>"C:\Program Files\GNU ARM Eclipse\QEMU\2.8.0-201612271623-dev\bin\qemu-system-gnuarmeclipse.exe"  -board NUCLEO-F103RB -mcu STM32F103RB --image BUILD\NUCLEO_F103RB\GCC_ARM\mbed-os-example-blinky.elf -verbose

GNU ARM Eclipse 64-bits QEMU v2.8.0 (C:\Program Files\GNU ARM Eclipse\QEMU\2.8.0-201612271623-dev\bin\qemu-system-gnuarmeclipse.exe).
Board: 'NUCLEO-F103RB' (ST Nucleo Development Board for STM32 F1 series).
Device: 'STM32F103RB' (Cortex-M3 r0p1, MPU, 4 NVIC prio bits, 43 IRQs), Flash: 128 kB, RAM: 20 kB.
Image: 'BUILD\NUCLEO_F103RB\GCC_ARM\mbed-os-example-blinky.elf'.
Command line: (none).
Cortex-M3 r0p1 core initialised.
Cortex-M3 r0p1 core reset.

Bad ram pointer 0000000000000000

This application has requested the Runtime to terminate it in an unusual way.
Please contact the application's support team for more information.

Note: I had to modify the mbed stm startup code a little to get to the error, else I had a hang on startup while the code was waiting for system clock registers to report as running (HAL_PWREx_EnableOverDrive(), __HAL_RCC_GET_FLAG(RCC_FLAG_HSERDY)

Debugging the startup code has it working fine through to the rtos startup configuration in svcRtxKernelGetState(). However I've failed to find anywhere to continue debugging from to find what's triggering the Bad ram pointer. I never get a breakpoint at pre_main() which the the first system thread which runs main, nor in the timer or idle threads. The SVC_Handler interrupt does fire, the PendSV_Handler does not.

I don't know where the code's at when qemu fails. Can you suggest whether there might be a qemu trace option that could give more info?

ilg-ul commented 6 years ago

then we might have two problems, one in the RCC peripheral and something related to the way RTX starts. actually I never tried QEMU in user mode.