search

ilg-archived / qemu

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

[Unimplemented USART]: register-bitfield.c:107: register_bitfield_is_non_zero: Assertion `obj' failed. #34

Open nix7965 opened 7 years ago

nix7965 commented 7 years ago

Hi, I try to run some RTOS called Nuttx (version 7.1.8) on gnuarmeclipse 2.8 However, I failed to doing it. So, I try to seek some advice for it.

I used the following option. --verbose --verbose --board STM32F429I-Discovery \ --mcu STM32F407VG -d unimp,guest_errors \ --image nuttx.elf \ #nuttx.elf = nuttx RTOS image --nographic \ --semihosting-config enable=on,target=native \ --semihosting-cmdline test 1 2 3

Here is the message after execution

GNU ARM Eclipse 64-bits QEMU v2.8.0 (qemu-2.8). Board: 'STM32F429I-Discovery' (ST Discovery kit for STM32F429/439 lines). Device file: '~/Work/qemu/install/qemu/share/qemu/devices/STM32F40x-qemu.json'. Device: 'STM32F407VG' (Cortex-M4 r0p0, MPU, 4 NVIC prio bits, 82 IRQs), Flash: 1024 kB, RAM: 128 kB. Image: 'nuttx.elf'. Command line: 'test 1 2 3' (10 bytes). Load 55308 bytes at 0x08000000-0x0800D80B. Load 2124 bytes at 0x0800D80C-0x0800E057. Cortex-M4 r0p0 core initialised. '/machine/mcu/stm32/RCC', address: 0x40023800, size: 0x0400 '/machine/mcu/stm32/FLASH', address: 0x40023C00, size: 0x0400 '/machine/mcu/stm32/PWR', address: 0x40007000, size: 0x0400 '/machine/mcu/stm32/SYSCFG', address: 0x40013800, size: 0x0400 '/machine/mcu/stm32/EXTI', address: 0x40013C00, size: 0x0400 '/machine/mcu/stm32/GPIOA', address: 0x40020000, size: 0x0400 '/machine/mcu/stm32/GPIOB', address: 0x40020400, size: 0x0400 '/machine/mcu/stm32/GPIOC', address: 0x40020800, size: 0x0400 '/machine/mcu/stm32/GPIOD', address: 0x40020C00, size: 0x0400 '/machine/mcu/stm32/GPIOE', address: 0x40021000, size: 0x0400 '/machine/mcu/stm32/GPIOF', address: 0x40021400, size: 0x0400 '/machine/mcu/stm32/GPIOG', address: 0x40021800, size: 0x0400 '/machine/mcu/stm32/GPIOH', address: 0x40021C00, size: 0x0400 '/machine/mcu/stm32/GPIOI', address: 0x40022000, size: 0x0400 '/machine/mcu/stm32/USART1', address: 0x40011000, size: 0x0400 '/machine/mcu/stm32/USART2', address: 0x40004400, size: 0x0400 '/machine/mcu/stm32/USART3', address: 0x40004800, size: 0x0400 '/machine/mcu/stm32/USART6', address: 0x40011400, size: 0x0400 '/peripheral/led:green' 108 @(519,109) active high '/machine/mcu/stm32/GPIOG',13 '/peripheral/led:red' 108 @(519,130) active high '/machine/mcu/stm32/GPIOG',14 QEMU 2.8.0 monitor - type 'help' for more information (qemu) Cortex-M4 r0p0 core reset.

qemu-2.8: /root/Work/qemu/gnuarmeclipse-qemu.git/hw/cortexm/register-bitfield.c:107: register_bitfield_is_non_zero: Assertion `obj' failed. ./run_2.8.sh: line 49: 48006 Aborted (core dumped) $QEMU --verbose --verbose --board $MACHINE --mcu STM32F407VG -d unimp,guest_errors --image nuttx.elf --nographic --semihosting-config enable=on,target=native --semihosting-cmdline test 1 2 3 QEMU terminated

ilg-ul commented 7 years ago

any reason for selecting the STM32F429I-Discovery board and the STM32F407VG device?

please remove the --mcu option and retry.

if it still fails, please attach the elf so I can test it myself.

nix7965 commented 7 years ago

binary.zip

Hi, I removed --mcu option. But, I found the same error. (I tested STM32F4-Discovery and STM32F429I-Discovery) This error was found with the previous qemu. I attached two files. Both files show the same error.

Note that both files are identical with different formats.

ilg-ul commented 7 years ago

with the elf file I was able to reproduce the problem. you are using an USART port, and the USART implementation is not yet functional.

temporarily remove the reference to USART and retry. if you used USART to output trace messages (bad idea anyway), replace them with the ITM or the semihosting channel.

USART is planned for the next release. it might be hilarious, but the main reason USARTs are not functional is that I do not have any USB-serial adapter for my Mac. :-(

nix7965 commented 7 years ago

Thank you. I am looking forward to releasing the next version.

ilg-ul commented 7 years ago

it might take a while.

don't you have a nuttx example that blinks the led and uses the button?

since nuttx is a bit unusual and does not use cmsis or hal, I'm curious if the custom startups and drivers are well supported on qemu.

bythefire commented 7 years ago

I had the same problem as @nix7965 with running NuttX and decided to try your suggestion and test with something less complicated (a "blinky" image). I found one version that was precompiled and source code to another.

The precompiled blinky fails with the same error even though it does not appear to make use of a UART.

The built from scratch blinky example is attached and gives a "rom check and register reset failed" error. I'm running qemu-system-gnuarmeclipse on macOS Sierra 10.12.2.

Details follow.

Precompiled

I tried a Precompiled Blinky and got the following.


GNU ARM Eclipse 64-bits QEMU v2.8.0 (qemu-system-gnuarmeclipse).
Board: 'STM32F4-Discovery' (ST Discovery kit for STM32F407/417 lines).
Board picture: '/Applications/GNU ARM Eclipse/QEMU/2.8.0-201612271623-dev/share/qemu/graphics/STM32F4-Discovery.jpg'.
Device file: '/Applications/GNU ARM Eclipse/QEMU/2.8.0-201612271623-dev/share/qemu/devices/STM32F40x-qemu.json'.
Device: 'STM32F407VG' (Cortex-M4 r0p0, MPU, 4 NVIC prio bits, 82 IRQs), Flash: 1024 kB, RAM: 128 kB.
Image: '/Users/jr/Downloads/blinky.elf'.
Command line: (none).
Load    136 bytes at 0x08000000-0x08000087.
Cortex-M4 r0p0 core initialised.
'/machine/mcu/stm32/RCC', address: 0x40023800, size: 0x0400
'/machine/mcu/stm32/FLASH', address: 0x40023C00, size: 0x0400
'/machine/mcu/stm32/PWR', address: 0x40007000, size: 0x0400
'/machine/mcu/stm32/SYSCFG', address: 0x40013800, size: 0x0400
'/machine/mcu/stm32/EXTI', address: 0x40013C00, size: 0x0400
'/machine/mcu/stm32/GPIOA', address: 0x40020000, size: 0x0400
'/machine/mcu/stm32/GPIOB', address: 0x40020400, size: 0x0400
'/machine/mcu/stm32/GPIOC', address: 0x40020800, size: 0x0400
'/machine/mcu/stm32/GPIOD', address: 0x40020C00, size: 0x0400
'/machine/mcu/stm32/GPIOE', address: 0x40021000, size: 0x0400
'/machine/mcu/stm32/GPIOF', address: 0x40021400, size: 0x0400
'/machine/mcu/stm32/GPIOG', address: 0x40021800, size: 0x0400
'/machine/mcu/stm32/GPIOH', address: 0x40021C00, size: 0x0400
'/machine/mcu/stm32/GPIOI', address: 0x40022000, size: 0x0400
'/machine/mcu/stm32/USART1', address: 0x40011000, size: 0x0400
'/machine/mcu/stm32/USART2', address: 0x40004400, size: 0x0400
'/machine/mcu/stm32/USART3', address: 0x40004800, size: 0x0400
'/machine/mcu/stm32/USART6', address: 0x40011400, size: 0x0400
'/peripheral/led:green' 8*10 @(258,218) active high '/machine/mcu/stm32/GPIOD',12
'/peripheral/led:orange' 8*10 @(287,246) active high '/machine/mcu/stm32/GPIOD',13
'/peripheral/led:red' 8*10 @(258,274) active high '/machine/mcu/stm32/GPIOD',14
'/peripheral/led:blue' 8*10 @(230,246) active high '/machine/mcu/stm32/GPIOD',15
'/peripheral/button:reset' 40*40 @(262,324)
'/peripheral/button:user' 40*40 @(262,164) active high '/machine/mcu/stm32/GPIOA',0
Cortex-M4 r0p0 core reset.

Assertion failed: (obj), function register_bitfield_is_non_zero, file /Users/ilg/Work/qemu/gnuarmeclipse-qemu.git/hw/cortexm/register-bitfield.c, line 107.
fish: './qemu-system-gnuarmeclipse --v…' terminated by signal SIGABRT (Abort)

Built from Scratch

I compiled a blinky.elf from the sources under Task-1-LED in these STM32F4 Examples and got the following result.


GNU ARM Eclipse 64-bits QEMU v2.8.0 (qemu-system-gnuarmeclipse).
Board: 'STM32F4-Discovery' (ST Discovery kit for STM32F407/417 lines).
Board picture: '/Applications/GNU ARM Eclipse/QEMU/2.8.0-201612271623-dev/share/qemu/graphics/STM32F4-Discovery.jpg'.
Device file: '/Applications/GNU ARM Eclipse/QEMU/2.8.0-201612271623-dev/share/qemu/devices/STM32F40x-qemu.json'.
Device: 'STM32F407VG' (Cortex-M4 r0p0, MPU, 4 NVIC prio bits, 82 IRQs), Flash: 1024 kB, RAM: 128 kB.
Image: '/Users/jr/playground/stm32f4-examples/Task-1-Leds/blinky.elf'.
Command line: (none).
Load   9024 bytes at 0x08000000-0x0800233F.
Load     40 bytes at 0x08002340-0x08002367.
Load   1024 bytes at 0x08002364-0x08002763.
Cortex-M4 r0p0 core initialised.
'/machine/mcu/stm32/RCC', address: 0x40023800, size: 0x0400
'/machine/mcu/stm32/FLASH', address: 0x40023C00, size: 0x0400
'/machine/mcu/stm32/PWR', address: 0x40007000, size: 0x0400
'/machine/mcu/stm32/SYSCFG', address: 0x40013800, size: 0x0400
'/machine/mcu/stm32/EXTI', address: 0x40013C00, size: 0x0400
'/machine/mcu/stm32/GPIOA', address: 0x40020000, size: 0x0400
'/machine/mcu/stm32/GPIOB', address: 0x40020400, size: 0x0400
'/machine/mcu/stm32/GPIOC', address: 0x40020800, size: 0x0400
'/machine/mcu/stm32/GPIOD', address: 0x40020C00, size: 0x0400
'/machine/mcu/stm32/GPIOE', address: 0x40021000, size: 0x0400
'/machine/mcu/stm32/GPIOF', address: 0x40021400, size: 0x0400
'/machine/mcu/stm32/GPIOG', address: 0x40021800, size: 0x0400
'/machine/mcu/stm32/GPIOH', address: 0x40021C00, size: 0x0400
'/machine/mcu/stm32/GPIOI', address: 0x40022000, size: 0x0400
'/machine/mcu/stm32/USART1', address: 0x40011000, size: 0x0400
'/machine/mcu/stm32/USART2', address: 0x40004400, size: 0x0400
'/machine/mcu/stm32/USART3', address: 0x40004800, size: 0x0400
'/machine/mcu/stm32/USART6', address: 0x40011400, size: 0x0400
'/peripheral/led:green' 8*10 @(258,218) active high '/machine/mcu/stm32/GPIOD',12
'/peripheral/led:orange' 8*10 @(287,246) active high '/machine/mcu/stm32/GPIOD',13
'/peripheral/led:red' 8*10 @(258,274) active high '/machine/mcu/stm32/GPIOD',14
'/peripheral/led:blue' 8*10 @(230,246) active high '/machine/mcu/stm32/GPIOD',15
'/peripheral/button:reset' 40*40 @(262,324)
'/peripheral/button:user' 40*40 @(262,164) active high '/machine/mcu/stm32/GPIOA',0
rom: requested regions overlap (rom phdr #2: /Users/jr/playground/stm32f4-examples/Task-1-Leds/blinky.elf. free=0x0000000008002368, addr=0x0000000008002364)
qemu-system-gnuarmeclipse: rom check and register reset failed
ilg-ul commented 7 years ago

Hi @bythefire,

I tried your first executable on my internal version, where the assert is fixed, the and I got the following messages:

stm32:usart-peripheral: Write of size 4 at offset 0x4 on disabled peripheral, ignored.
stm32:usart-peripheral: Write of size 4 at offset 0x10 on disabled peripheral, ignored.
...

So it appears you are still using the USART.

I confess that my experience with NuttX is minimal, and my attempt to totally disable the use of USART was not successful, so this might not be easy.

For the second test, can you attach the elf file so I can run it in the debugger?

ilg-ul commented 7 years ago

@bythefire,

if you want to test a functional blinky, I suggest you try https://github.com/micro-os-plus/eclipse-demo-projects/tree/master/f4discovery-blinky-micro-os-plus

or even the official blinky sample: http://gnuarmeclipse.github.io/tutorials/blinky-arm/

ilg-ul commented 7 years ago

one more thing: the blinky samples I saw in nuttx use pwm to control the led. well, although for low speed it might work, it is not reasonable to expect this to work well in an emulator. (timers will be implemented in a future version).

bythefire commented 7 years ago

Thanks for the tips. Here's a link to the blinky I compiled: https://github.com/gnuarmeclipse/qemu/files/692353/blinky-fromscratch.elf.zip.

ilg-ul commented 7 years ago

I don't know how you generated that file, but the last two sections overlap:

Load   9024 bytes at 0x08000000-0x0800233F.
Load     40 bytes at 0x08002340-0x08002367.
Load   1024 bytes at 0x08002364-0x08002763.
ilg-ul commented 7 years ago

For the precompiled blinky the size is surprisingly small:

Load    136 bytes at 0x08000000-0x08000087.

The STM32F407 has 16+82 exception vectors, which occupy the first 392 bytes, so your linker files might not be realistic.

Do your tests really run on the physical board?

bythefire commented 7 years ago

Unfortunately, I don't have a physical board to test on. I'm trying to avoid using eclipse and establish a minimal setup with make/gcc/ld. That might explain why the ELF I compiled is off. Do you have a precompiled blinky that is known to work?

ilg-ul commented 7 years ago

I'm trying to avoid using eclipse and establish a minimal setup with make/gcc/ld.

you don't know what you are missing.

ilg-ul commented 7 years ago

a precompiled blinky that is known to work?

try f407-disc-blink.elf.zip.

it should blink the 4 LEDs and the two buttons should also be functional.

bythefire commented 7 years ago

Thanks @ilg-ul, confirmed that it works. I also got mine working without eclipse. I compressed them both to compare image sizes and included the results below.

292800 f407-disc-blink.elf.gz
5374   blinky.elf.gz

Here's blinky.elf.gz if you're curious.

ilg-ul commented 7 years ago

to compare image sizes

and what does this comparison mean? please elaborate.

where are the sources of the project used to generate your elf?

ilg-ul commented 7 years ago

Here's blinky.elf.gz if you're curious.

I was curious, and ran it in qemu, but it blinks extremely quickly, not at a 1 Hz rate, as expected. and apparently nothing happens if I press the user button.

bythefire commented 7 years ago

Here is the source. It does not monitor the buttons for input. The timing in delay() might be incorrect as it seems it should toggle one of four LEDs every 250ms (4Hz).

ilg-ul commented 7 years ago

it should toggle one of four LEDs every 250ms (4Hz)

really? take a look again at your code and point to the location where you measure 250ms. don't rush to the delay function, since the time required to executes 3360 NOP instructions depends on the core frequency and compiler optimisation level.

fyi, code running inside qemu runs much, much faster than on physical hardware. the correct solution is to use a timer, like SysTick, which is implemented more or less accurate by qemu.

bythefire commented 7 years ago

That's the assumption at line 30: delay(250);, since delay expects an argument in milliseconds, it would delay for 250ms if things worked right. But like you said, the method used to track time is fraught with peril. I didn't write this code... just appropriated it to play with your awesome qemu fork! :)