diff options
| author | Christian Krinitsin <mail@krinitsin.com> | 2025-06-01 21:35:14 +0200 |
|---|---|---|
| committer | Christian Krinitsin <mail@krinitsin.com> | 2025-06-01 21:35:14 +0200 |
| commit | 3e4c5a6261770bced301b5e74233e7866166ea5b (patch) | |
| tree | 9379fddaba693ef8a045da06efee8529baa5f6f4 /gitlab/issues_text/target_avr/host_missing/accel_missing/1525 | |
| parent | e5634e2806195bee44407853c4bf8776f7abfa4f (diff) | |
| download | qemu-analysis-3e4c5a6261770bced301b5e74233e7866166ea5b.tar.gz qemu-analysis-3e4c5a6261770bced301b5e74233e7866166ea5b.zip | |
clean up repository
Diffstat (limited to 'gitlab/issues_text/target_avr/host_missing/accel_missing/1525')
| -rw-r--r-- | gitlab/issues_text/target_avr/host_missing/accel_missing/1525 | 78 |
1 files changed, 0 insertions, 78 deletions
diff --git a/gitlab/issues_text/target_avr/host_missing/accel_missing/1525 b/gitlab/issues_text/target_avr/host_missing/accel_missing/1525 deleted file mode 100644 index aec01b592..000000000 --- a/gitlab/issues_text/target_avr/host_missing/accel_missing/1525 +++ /dev/null @@ -1,78 +0,0 @@ -Wrong initial value of stack pointer on AVR devices -Description of problem: -The initial value of stack pointer of AVR MCUs should be RAMEND (address of the end of their RAM), but QEMU initialize them to 0. - -`qemu-system-avr -machine help` lists 4 flavors of MCUs which are ATmega168, ATmega2560, ATmega1280, ATmega328P. According to their datasheets, the stack pointer should be initialized as follows on reset. - -- [ATmega168](https://ww1.microchip.com/downloads/en/DeviceDoc/Atmel-9365-Automotive-Microcontrollers-ATmega88-ATmega168_Datasheet.pdf#page=12): RAMEND (which is 0x04FF) -- [ATmega2560 and ATmega1280](https://ww1.microchip.com/downloads/en/devicedoc/atmel-2549-8-bit-avr-microcontroller-atmega640-1280-1281-2560-2561_datasheet.pdf#page=15): RAMEND (which is 0x21FF) -- [ATmega328P](https://ww1.microchip.com/downloads/aemDocuments/documents/MCU08/ProductDocuments/DataSheets/ATmega48A-PA-88A-PA-168A-PA-328-P-DS-DS40002061B.pdf#page=22): RAMEND (which is 0x08FF) -Steps to reproduce: -1. Assemble the assembly code below: `avrasm2 -fI test.asm` - - ```asm - ;; test.asm - .INCLUDE "m328Pdef.inc" - - .EQU F_CPU = 16000000 - .EQU BAUD_RATE = 9600 - .EQU PRESCALE = (F_CPU / (16 * BAUD_RATE)) - 1 - - .CSEG - start: - ;; initialize USART (serial port) - LDI R16, LOW(PRESCALE) - LDI R17, HIGH(PRESCALE) - STS UBRR0L, R16 - STS UBRR0H, R17 - LDI R16, (1 << RXEN0) | (1 << TXEN0) - STS UCSR0B, R16 - - ;; Get stack pointer low byte and print it in ASCII - IN R16, SPL - LDI R17, 0x30 - ADD R16, R17 - print1: - LDS r17, UCSR0A - SBRS r17, UDRE0 - RJMP print1 - STS UDR0, r16 - - ;; Get stack pointer high byte and print it in ASCII - IN R16, SPH - LDI R17, 0x30 - ADD R16, R17 - print2: - LDS r17, UCSR0A - SBRS r17, UDRE0 - RJMP print2 - STS UDR0, r16 - - end: - RJMP end - ``` - -2. Convert it to bin file: `avr-objcopy --input-target=ihex --output-target=binary test.hex test.bin` - -3. Run it with QEMU: `qemu-system-avr -machine uno -bios test.bin -serial stdio` - -This should print 00 which means that the stack pointer is initialized to 0. -Additional information: -I examined the source code and I think that editing the function `avr_cpu_reset_hold` in `/target/avr/cpu.c` might fix this issue. This is my first time seeing QEMU source code, so I might be wrong, though. - -```c -// in /target/avr/cpu.c line 70 -static void avr_cpu_reset_hold(Object *obj) -{ - // ... - - env->rampD = 0; - env->rampX = 0; - env->rampY = 0; - env->rampZ = 0; - env->eind = 0; - env->sp = 0; // <-- change this value in accordance with board type? - - //... -} -``` |