Fix Vector Table Alignement for Vorago va416x0

[jgeorge1316]

Fix Vector Table Alignment - Vorago VA416x0

From Cortex-M4 Devices Generic User Guide - 4.3.4 Vector Table Offset Register:

When setting TBLOFF, you must align the offset to the number of exception entries in the vector
table. The minimum alignment is 32 words, enough for up to 16 interrupts. For more interrupts,
adjust the alignment by rounding up to the next power of two.

• From VA416xx_SDK -> startup_va416xx.s, there are 196 interrupts, as well as the Cortex-M4 base 16 exceptions.
• There are 212 total interrupts. To meet the alignment requirements, the vector table offset must align with a 256-word (1024 byte) boundary.

Increasing IMAGE_HEADER_SIZE in config/examples/vorago_va416x0.config allows the vector table offset to meet this requirement.

[embhorn]

@jgeorge1316 Thanks for sending the CLA request to our support email..

[dgarske]

Hi @jgeorge1316 even though the ARMv7-M manual states 1024 byte alignment requirement this part does not require it from my testing. Are you actually seeing an issue? Can you tell me more about your project and use of the Vorago hardware? I assume this is academic? Did you actually test on hardware?
Thanks, David Garske, wolfSSL

[jgeorge1316]

Hello David, in brief:

• This is a professional project using a custom board with the Vorago VA41630
• I saw the issue when testing on hardware

Verbose description below:

Project

Goal:

See if wolfBoot could be used as a bootloader on our device to allow secure updates.

Description

I have testing using wolfBoot as a bootloader for prototyping improvements to GPS Disciplined OCXO. This is a professional endeavour. I created a copy of wolfBoot for this because I modified va416x0.c & va416x0.h. I kept this private as a precaution as the code contained pin configuration for our custom board.

Utilizing wolfBoot

I began my prototyping by adding simple uart drivers and file transfer protocol to receive a update. This did use some UART IRQs, and this worked without issue.

Issue

Once I had working updates, I ported the code from our application. This featured more IRQs (timers, external interrupts, etc.). I noticed that when certain interrupts were triggered, the device would lockup and a watchdog reset would be triggered.

Troubleshoot Issue

• I compiled the same code as a standalone application. This used the same project but disabled calls to wolfBoot api in the application. The device did not lockup in this case. ✅
• I compiled the code to run as a wolfBoot app again. This time I disabled the watchdog and used a debuger to inspect some registers when the code was frozen. I noticed that the microcontroller seemed to be at the Default_Handler, which triggers an infinite loop. ❌
• I found that info in the ARM docs with the help of AI, so I tried increasing the IMAGE_HEADER_SIZE as the simplest way to allow the table offset from VTOR to align properly while still meeting wolfBoot partition rules. The code worked after this change. ✅

I think the UART interrupts worked because they are lower-numbered interrupts in the table, but the interrupt causing the issue was a much higher number pin-interrupt. I chose to make these suggestions using my personal GitHub account since my company GitHub account has not made any commits to any public repositories.

[dgarske]

Hi @jgeorge1316 would you mind sending an email to facts at wolfssl dot come and referencing this PR and your region? It would be great to have a short call and discuss further. Since this PR is small we decided to treat as a bug report and implement outselves. I've got a new PR open to address this here #897 So for now I will go ahead and close this one. Looking forward to your email and discussion about wolfBoot on the Vorago part. Thanks, David Garske, wolfSSL