Experimentation with Adafruit ItsyBitsy M4 board

Discuss anything not related to the current Uzebox design like successors and other open source gaming hardware
User avatar
Jubatian
Posts: 1560
Joined: Thu Oct 01, 2015 9:44 pm
Location: Hungary
Contact:

Re: Experimentation with Adafruit ItsyBitsy M4 board

Post by Jubatian »

You could do the ordinary Uzebox-like sync to timer, definitely, it will work. Just make sure you run that part from RAM, possibly by studying that cache a bit to lock that part in the cache (it doesn't appear to be too difficult at glance).

When entering an interrupt, the Cortex M4 automatically pushes an Exception Frame on the stack, which is 8 registers: the equivalent of SREG (PSR) is included. The others are the PC, the Link Register, and R0, R1, R2, R3 and R12. The ARM core by the way is not documented in typical vendor datasheets, you can gather the details from ARM (The website is quite a pain to use, but usually there are PDF links, you should be able to find the generic user guide & technical reference manual of the Cortex M4 core there. I still had no luck finding some document listing the binary encodings of opcodes which would be quite essential for an emulator).

Not a lot of experience though, just was hurled in the deep right away at my new job in the UK.
User avatar
mast3rbug
Posts: 81
Joined: Sat Jan 08, 2011 8:15 am

Re: Experimentation with Adafruit ItsyBitsy M4 board

Post by mast3rbug »

Thanks for the information.

Today, I tried to put some Assembly code in RAM with .data section. It crashed automatically at the first instruction to the dummy handler interrupt. DO you know what I missed here? What is the proper way to put code in RAM?

Cedric
User avatar
Jubatian
Posts: 1560
Joined: Thu Oct 01, 2015 9:44 pm
Location: Hungary
Contact:

Re: Experimentation with Adafruit ItsyBitsy M4 board

Post by Jubatian »

There could be a few reasons, maybe first check the followings:
  • Is the code halfword aligned (2 byte alignment)? It may happen that it isn't, then that would be a problem.
  • When you are preparing the transfer instruction, do you set the lowest bit of the register which you use with the BLX instruction? It needs to be set to identify Thumb mode (0 would be ARM mode, the original 32 bit instruction set, which was removed from the Cortex).
  • It might be that the RAM is marked non-executable by default in the Memory Management Unit (I dunno about this part for now, it could be that such doesn't exist at all, but I wouldn't be surprised if it existed).
  • If you are setting up the interrupt vector directly to have the interrupt code in RAM, it might demand more strict alignment (4 byte? 8 byte?). Also in the vector table you have to have the lowest bit of the vector set 1 (Thumb mode, again).
Hope one of these catches it!
User avatar
mast3rbug
Posts: 81
Joined: Sat Jan 08, 2011 8:15 am

Re: Experimentation with Adafruit ItsyBitsy M4 board

Post by mast3rbug »

Is the code halfword aligned (2 byte alignment)? It may happen that it isn't, then that would be a problem.
I made .align 4 just before the function, followed by the .thumb_func (like all the other ASM function in the others flash code, if not, it also crash in the Handler interrupt) Let me know if something is wrong in this.
When you are preparing the transfer instruction, do you set the lowest bit of the register which you use with the BLX instruction? It needs to be set to identify Thumb mode (0 would be ARM mode, the original 32 bit instruction set, which was removed from the Cortex).
Not sure what you mean by "Transfer instruction", I set nothing, but in the assembly code, I put .thumb_func like usual. By default, I think the Atmel studio set the MCU in the thumb2 mode but not the Assembler, and this is why we have to puth the .thumb_func before each function in assembly or it will crash to the dummy interrupt handler. I think all is good for this one.
It might be that the RAM is marked non-executable by default in the Memory Management Unit (I dunno about this part for now, it could be that such doesn't exist at all, but I wouldn't be surprised if it existed).
Okey, this one can be the potential problem, I will check for that.
If you are setting up the interrupt vector directly to have the interrupt code in RAM, it might demand more strict alignment (4 byte? 8 byte?). Also in the vector table you have to have the lowest bit of the vector set 1 (Thumb mode, again).
The interrupt vector is in C, in the normal flash program execution, I can see in Disassembly mode that the interrupt jump from Flash address to Ram address, and right after reaching the furst instruction in RAM, the next step in debug mode jump into the dummy interrupt handler. Also, same thing for the Thumb mode, I set the same preprocessor instruction .thumb_func, so I think this one is correct too.

Cedric
User avatar
Jubatian
Posts: 1560
Joined: Thu Oct 01, 2015 9:44 pm
Location: Hungary
Contact:

Re: Experimentation with Adafruit ItsyBitsy M4 board

Post by Jubatian »

So you have a debugger! That could make tracking this down easier. Check the CFSR register (might be accessible as NVIC.CFSR or something like that), it contains the cause of a fault exception if any happens. Some details on this can be found on some compiler vendors' technical documents, IAR and KEIL. The compiler / IDE is mostly irrelevant, the point is how this could be used to help tracing down what is happening. If you can't watch it directly, probably copy it off into a volatile variable (prevent the compiler optimizing it away) before the infinite loop in the default handler, and watch / check the contents of the variable.
CunningFellow
Posts: 1445
Joined: Mon Feb 11, 2013 8:08 am
Location: Brisbane, Australia

Re: Experimentation with Adafruit ItsyBitsy M4 board

Post by CunningFellow »

VGA (640x480) timing is 800 total clocks per line at 25Mhz.

Have you considered just DMAing 800 bytes to the port in an endless loop and having the timers make the syncs. Just leave the first 112 and the last 48 bytes zero and only write to the middle 640.

Or you could waste 1600 bytes and ping-pong odd/even lines. I am pretty sure the SAM DMA I have used had a ping-pong mode.

If the TOC module and the DMA both had the same 25/50/100 Mhz clock you would likely get no jitter.
User avatar
mast3rbug
Posts: 81
Joined: Sat Jan 08, 2011 8:15 am

Re: Experimentation with Adafruit ItsyBitsy M4 board

Post by mast3rbug »

VGA (640x480) timing is 800 total clocks per line at 25Mhz.
Have you considered just DMAing 800 bytes to the port in an endless loop and having the timers make the syncs. Just leave the first 112 and the last 48 bytes zero and only write to the middle 640.
Or you could waste 1600 bytes and ping-pong odd/even lines. I am pretty sure the SAM DMA I have used had a ping-pong mode.
If the TOC module and the DMA both had the same 25/50/100 Mhz clock you would likely get no jitter.
Yes this was something I was thinking about trying, but by the chip documentation, the DMA proccess can't be slowed down, so the pixels output will go too fast for this option at 120 MHz. Also, not sure if the DMA request will induce a small jitter from the acess request to the bus while the CPU finish the actual insruction execution? At least, this is the way ATXMEGA works for DMA access, so real time access with DMA make things not more practical than regular delay equalisation from a regular interrupt.
So you have a debugger! That could make tracking this down easier. Check the CFSR register (might be accessible as NVIC.CFSR or something like that), it contains the cause of a fault exception if any happens. Some details on this can be found on some compiler vendors' technical documents, IAR and KEIL. The compiler / IDE is mostly irrelevant, the point is how this could be used to help tracing down what is happening. If you can't watch it directly, probably copy it off into a volatile variable (prevent the compiler optimizing it away) before the infinite loop in the default handler, and watch / check the contents of the variable.
Yes I have a debugger, I have a Atmel ICE, sorry for not mentionning it at the beginning, I don't know what developpers here are using, but for the actual UZEBOX programming an AVR DRAGON is the bare minimum to make debug on the game development? By the way, AVR have a simulator in Atmel studio, but ARM have not. This make debugging even harder to do. I will try to check what you said and come back soon. Thanks again for the help.


Cedric
CunningFellow
Posts: 1445
Joined: Mon Feb 11, 2013 8:08 am
Location: Brisbane, Australia

Re: Experimentation with Adafruit ItsyBitsy M4 board

Post by CunningFellow »

mast3rbug wrote: Sun Feb 17, 2019 11:58 am the DMA proccess can't be slowed down, so the pixels output will go too fast for this option at 120 MHz. Also, not sure if the DMA request will induce a small jitter from the acess request to the bus while the CPU finish the actual insruction execution? At least, this is the way ATXMEGA works for DMA access, so real time access with DMA make things not more practical than regular delay equalisation from a regular interrupt.
DMA has to be able to be slowed down. Otherwise it would be useless for comminications things that are slower than the CPU clock.

Look in the datasheet for "conditional transfer on strobe"

You should be able to make a timer produce a 25.17Mhz tick from a 100.68 Mhz main clock for this.

Also the HSB Matrix should be able to connect the DMA to the peripheral bus and some SRAM bank without clashing with the CPU reading from flash and a different SRAM bank.
User avatar
mast3rbug
Posts: 81
Joined: Sat Jan 08, 2011 8:15 am

Re: Experimentation with Adafruit ItsyBitsy M4 board

Post by mast3rbug »

DMA has to be able to be slowed down. Otherwise it would be useless for comminications things that are slower than the CPU clock.
Look in the datasheet for "conditional transfer on strobe"
You should be able to make a timer produce a 25.17Mhz tick from a 100.68 Mhz main clock for this.
Also the HSB Matrix should be able to connect the DMA to the peripheral bus and some SRAM bank without clashing with the CPU reading from flash and a different SRAM bank.
Fine. I will read again the documentation about DMA. There is no mention about end cycles latency betwen CPU halt and DMA bus request for SRAM read. If it's irrevelant, it will work for sure.

I had time to adapt my 3d engine from my other Atxmega console, here a small video of the first moving graphics I'v done. Still some bug in the display, and I'm not using any page swap at the moment, only clear screen and redraw. Not too bad for first 3d object :D.

User avatar
Jubatian
Posts: 1560
Joined: Thu Oct 01, 2015 9:44 pm
Location: Hungary
Contact:

Re: Experimentation with Adafruit ItsyBitsy M4 board

Post by Jubatian »

Huh, this looks quite neat, it isn't even just a wireframe object there! :)

I just didn't see it obvious that one necessarily has a debugger and tools as I never had one for the AVR, only a cheap programmer. It is a simple micro, and quite well emulated. With the various bootloaders and-or simple upload mechanics around it may be possible to mess around with hardware without an actual debugger, however with the ARM it may sure get excruciatingly painful at times!

By the way for some tricks on setting up stuff on an ARM, you may check the BitBox repo, it is mostly done at bare metal level, although for an STM32F4. But some ideas could be useful for approaching the problem.
Post Reply