SoC
  • Home
  • Arm
  • Arm Cortex M0/M0+
  • Arm Cortex M4
  • Arm Cortex M3
  • Contact
Reading: Common Errors in Cortex-M1 Vector Table Setup
SUBSCRIBE
SoCSoC
Font ResizerAa
  • Home
  • Arm
  • Arm Cortex M0/M0+
  • Arm Cortex M4
Search
  • Home
  • Arm
  • Arm Cortex M0/M0+
  • Arm Cortex M4
Have an existing account? Sign In
Follow US
  • Looking for Something?
  • Privacy Policy
  • About Us
  • Sitemap
  • Contact Us
© S-O-C.ORG, All Rights Reserved.
Arm

Common Errors in Cortex-M1 Vector Table Setup

Eileen David
Last updated: September 17, 2023 9:24 am
Eileen David 11 Min Read
Share
SHARE

When setting up the vector table for a Cortex-M1 processor, there are some common errors that developers can make which will cause issues. The vector table is critical for handling exceptions and interrupts properly on the Cortex-M1. Avoiding these common mistakes will ensure your Cortex-M1 application runs smoothly without unexpected crashes or hangs.

Contents
Forgetting the Initial Stack PointerIncorrect Exception Handler AddressesNot Enabling ExceptionsFaulty NVIC ConfigurationNot Enabling VFPWrong Vector Table OffsetNot Handling ExceptionsImproper Debug ConfigurationNot Saving Context on ExceptionBad Hard Fault HandlerIncorrect Linker Region SizesWeak Reset HandlerNo Bootloader InitializationUsing Invalid Memory RegionsOverwriting Flash MemoryInterrupt IssuesPoor Code OptimizationInvalid Compiler FlagsConclusion

Forgetting the Initial Stack Pointer

One of the most common errors is forgetting to set the initial stack pointer in the vector table. The stack pointer register should point to the start of the stack memory region on startup. Without setting this up properly, the processor will not have a stack to use when handling exceptions and interrupts which can lead to hard faults or other issues.

To avoid this, make sure to define the stack memory region and set the initial stack pointer register in the 0th entry of the vector table to point to the start of the stack. For example: .stack : { . = ALIGN(8); _stack_start = .; . = . + STACK_SIZE; . = ALIGN(8); _stack_end = .; } .vector_table : { . = ALIGN(4); _vtable = .; VTABLE_ENTRY .stack_end // rest of vector table }

Incorrect Exception Handler Addresses

The Cortex-M1 vector table contains the addresses for all the exception handlers. Getting any of these addresses wrong will lead to problems or crashes when that particular exception occurs.

Double check that the handler functions for each exception have the correct address in the vector table. It’s easy to accidentally point to the wrong function. Testing out each exception handler individually can help catch any wrong addresses.

Not Enabling Exceptions

In order for exceptions and interrupts to be processed correctly, the appropriate enables need to be set in the Application Interrupt and Reset Control Register (AIRCR). This includes enabling the PRIMASK and FAULTMASK registers.

If these enables are not set properly, exceptions and interrupts can be ignored which can lead to unusual behavior. Make sure to read the register documentation and enable the right bits for the exceptions you need.

Faulty NVIC Configuration

The Cortex-M1 Nested Vectored Interrupt Controller (NVIC) needs to be configured properly to handle external interrupts. This includes setting up the right priority grouping and priority levels for each interrupt.

Improper priority grouping can result in interrupts being blocked incorrectly. And incorrect priority levels can cause important interrupts to be delayed for too long. Take time to plan out the NVIC priority grouping and priority levels when setting up the vector table.

Not Enabling VFP

The Cortex-M1 includes an optional floating point unit (VFP) which needs to be explicitly enabled. If the VFP is used without enabling it, the processor will crash with a usage fault exception.

Make sure to enable the VFP in the Application Interrupt and Reset Control Register if floating point operations are used. And implement the VFP exception handler to catch any floating point exceptions.

Wrong Vector Table Offset

The Cortex-M1 vector table offset register controls where in memory the processor looks for the vector table on boot. This needs to match where the vector table is located in the memory map.

If the offset is incorrect, the processor will read the wrong memory addresses for the vector table entries leading to crashes or other erratic behavior. Double check this offset matches the linker script vector table placement.

Not Handling Exceptions

While the vector table provides default exception handlers, these typically just loop indefinitely. Proper exception handlers need implemented for faults, interrupts, and system exceptions.

Without handling exceptions like memory faults, bus faults, interrupts etc., it will not be possible to recover from them and the system will hang. Implement handlers for the exceptions you need to handle in your application.

Improper Debug Configuration

To debug code via JTAG and debug probes, the Cortex-M1 debug registers need configured properly. This includes setting the right halt conditions and access permissions.

Incorrect debug configuration can make it impossible to halt the core or access memory when debugging. Consult the documentation on the Debug Exception and Monitor Control Register to enable debugging properly.

Not Saving Context on Exception

When an exception occurs, the processor state context (registers, stack, etc.) need saved by the handler if you want to return and resume where the exception occurred. The handler needs to push registers onto the stack.

Without saving the context, returning from the handler will be back at some random state leading to crashes or strange bugs. Make saving the register states part of your exception handling routines.

Bad Hard Fault Handler

The hard fault handler is called when an exceptional error condition occurs and needs robust handling. At minimum it should loop forever, but ideally would give some debug information.

Having a weak hard fault handler can result in returning from the handler to an unknown state and lead to data corruption or crashes later on. Take time to implement a robust hard fault handler.

Incorrect Linker Region Sizes

The linker script defines the memory regions for different code and data segments. Having incorrect sizes here can result in some memory being inaccessible or overwritten.

Double check the region sizes, especially the stack and heap sizes, match the required amounts for your program. Incorrect sizes will lead to weird crashes and corruption issues.

Weak Reset Handler

The processor will start executing from the reset handler on boot. This needs to perform essential startup tasks like copying data sections to RAM, zero initializing BSS, and calling main().

With a minimal reset handler, the C runtime will not initialize properly and calling main() may never occur. This would prevent the application from starting up correctly after reset.

No Bootloader Initialization

Many Cortex-M1 systems use a bootloader to perform essential system initialization like configuring clocks and memory. If using a bootloader, the reset handler needs to jump to the bootloader entry point.

Skipping the bootloader initialization will mean the clocks and memory are not configured right for the Cortex-M1 leading to crashes or freezes on reset. The reset handler should immediately pass control to the bootloader if one exists.

Using Invalid Memory Regions

The Cortex-M1 memory map will contain defined regions for RAM, peripherals, and memory-mapped I/O. Trying to access memory outside valid regions will fail.

Attempting invalid memory access will typically cause a memory management fault leading to a crash. Ensure code and data memory access is constrained to the defined valid regions.

Overwriting Flash Memory

The flash memory containing code may have limitations on writes or require erase cycles before writes. Attempting too many writes without erasing can overwrite flash memory incorrectly.

This can lead to crashes immediately or down the road as flash memory is corrupted. Understand the limitations of the flash memory hardware and ensure the code performs erase cycles when needed before writes.

Interrupt Issues

There are a couple common issues that can occur with handling interrupts in the Cortex-M1 vector table:

  • Forgetting to clear the pending interrupt: Interrupts will keep firing unless the pending bit is cleared in the NVIC.
  • Interrupt handler taking too long: Handlers should be short to avoid delaying other interrupts. Perform the minimum possible work in the handler.
  • Accessing invalid data: Interrupt context often has limitations on what data can be accessed safely. Follow any data restrictions when accessing data in handlers.

Properly clearing interrupts, keeping handlers short, and safely accessing data will avoid a lot of subtle and difficult to debug interrupt issues.

Poor Code Optimization

Well optimized code is important for Cortex-M1 performance. The compiler can optimize for speed or size which impacts performance.

If using speed optimizations, make sure to validate any timing requirements are still met. And if using size optimizations, check that performance is still acceptable and not too degraded.

Finding the right balance between speed, size, and performance for a given application takes some trial and error. Profiling the code can help make good optimization decisions.

Invalid Compiler Flags

The compiler flags control the optimizations, defines, includes, and other build settings. Using incorrect flags can lead to subtle issues.

For example, enabling optimizations like loop unrolling without proper testing can lead to code size increasing too much. Or disabling certain optimizations can degrade performance unnecessarily.

Validate any compiler flag changes through testing before deployment. Improper compiler flags can be difficult issues to identify and debug.

Conclusion

Setting up the Cortex-M1 vector table correctly is critical for a properly functioning system. Taking the time to avoid these common errors will help prevent frustrating crashes, hangs, and bugs. Implementing solid exception handling and testing each vector table entry will help validate everything is configured right.

Robust error handling on the Cortex-M1 provides the foundation for building reliable and stable embedded and IoT applications on this versatile ARM processor.

Newsletter Form (#3)

More ARM insights right in your inbox

 


Share This Article
Facebook Twitter Email Copy Link Print
Previous Article Debugging tips for Cortex-M1 vector table configuration
Next Article Setting Stack Size and Heap Size in Cortex-M1 Vector Table
Leave a comment Leave a comment

Leave a Reply Cancel reply

Your email address will not be published. Required fields are marked *

2k Followers Like
3k Followers Follow
10.1k Followers Pin
- Sponsored-
Ad image

You Might Also Like

What is Computer architecture in Arm Cortex-M series?

The ARM Cortex-M series of processors are designed for embedded…

9 Min Read

KEIL ULINK2 and ACTEL Cortex-M1 debugging issues

When debugging ARM Cortex-M1 chips using the KEIL ULINK2 debugger,…

7 Min Read

Assessing Code Safety with GNU-ARM for Cortex-M0/M1

The GNU ARM Embedded Toolchain provides a robust set of…

7 Min Read

Is CMSIS a library?

Yes, CMSIS stands for Cortex Microcontroller Software Interface Standard and…

7 Min Read
SoCSoC
  • Looking for Something?
  • Privacy Policy
  • About Us
  • Sitemap
  • Contact Us
Welcome Back!

Sign in to your account