Configuring Cortex-M1 Reset Behavior When Using External BRAM

When using external BRAM with the Cortex-M1 processor, it is important to properly configure the reset behavior to ensure correct system operation. The Cortex-M1 supports flexible reset configurations to accommodate different use cases. This article provides guidance on configuring the start-up reset behavior when integrating external BRAM with Cortex-M1.

Overview of Cortex-M1 Reset

The Cortex-M1 processor has multiple reset sources that can trigger a system reset. These include power-on reset, external reset pin, watchdog reset, and software initiated reset. On reset, the processor will load the reset value from the start-up reset register which controls the initial boot behavior.

During the reset sequence, the processor also asserts the system reset signal to reset any on-chip peripherals and external logic. It is important that the timing of the system reset aligns with the power levels reaching the specified operation range for the external BRAM.

Start-up Reset Configuration

The start-up reset register in the Cortex-M1 controls the processor’s initial boot behavior. There are two primary configuration options:

• Reset into ROM – The processor will start executing code from the on-chip boot ROM. This can be used to copy code from external flash into internal SRAM before jumping to the main application.
• Reset into RAM – The processor will start executing code directly from a defined location in SRAM or external memory. This allows jumping directly into the application without any bootloader sequence.

When using external BRAM to hold the program code, the start-up reset register should be configured for reset into RAM. The address field should specify the starting address of the code in the BRAM device. This causes the processor to begin fetching instructions directly from that location on reset.

Timing Considerations

Proper operation requires the system reset to be de-asserted after the external BRAM has reached the specified supply voltage levels. The reset signal should be timed to meet the BRAM power-up requirements. There are several approaches to manage this timing:

• System reset supervisor – An external reset supervisor circuit can monitor the supply rails and control the system reset timing.
• Processor reset controller – Some Cortex-M1 implementations have programmable reset timing in the processor reset controller block.
• External delay – A simple RC delay on the reset pin can introduce delay to meet BRAM timing needs.

Consult the BRAM datasheet specifications to determine the required power-up timing. The system reset should be held active until these requirements are satisfied.

Reset Configuration Settings

The Cortex-M1 reset configuration is managed through several registers in the system control block. Key settings include:

• AIRCR – Application Interrupt and Reset Control Register. This controls software initiated resets and priority of different reset sources.
• RVSR – Reset Value Status Register. Indicates source of last reset.
• RMR – Reset Management Register. Used to enable reset for configurable external pin.
• RESET_MISC – Reset Misc Register. Configures reset to ROM or RAM and start address.

These registers can be configured through the CMSIS System Initialization function which is called early in the reset sequence. This allows central configuration of the reset behavior.

Initializing External BRAM

At power-on the external BRAM will not have a valid state until configured by the Cortex-M1 system. The processor needs to sequence the BRAM initialization which typically involves:

1. Asserting the BRAM reset pin
2. Programming the BRAM configuration register settings
3. Initializing memory contents
4. Releasing BRAM reset

This sequence needs to occur early in the Cortex-M1 reset process prior to jumping to the main application code. There are several approaches:

• Bootloader – Implement a bootloader sequence in internal ROM or flash that initializes BRAM.
• System co-processor – Use system co-processor to initialize BRAM after power-on reset.
• Discrete logic – Add a small state machine to control BRAM reset and configuration.

The best approach depends on the specific system architecture and boot requirements. The key is ensuring the BRAM is ready prior to Cortex-M1 trying to fetch code from the device address range.

Reset and Exception Handling

The Cortex-M1 provides dedicated exception handling for different types of faults and errors. These include:

• Hard fault – For unrecoverable errors like bus faults or undefined instructions.
• NMI – Non-maskable interrupt pin for high priority interrupts.
• Memory management faults – For MMU errors if enabled.
• Bus fault – For external bus errors on instruction or data accesses.

It is useful to have an exception handler specifically for bus faults. This allows detecting and handling any bus errors when accessing external BRAM. The handler can simply trap and report the error for debug purposes.

USB based debugging tools like J-Link include breakpoint support that can automatically halt the processor and capture the register state when any exception occurs. This greatly simplifies analyzing the cause of any exceptions or faults when accessing external memory.

Debugging Considerations

Using external BRAM introduces some unique debugging considerations for Cortex-M1:

• Memory accesses will incur additional latency which can alter real-time behavior. Tight timing may need adjustment.
• Debug suspend logic can override BRAM controls leading to contention. Use debug module peripheral controls.
• Memory errors may not be detected cleanly leading to uncertainty about state. Consider ECC or parity protection.
• Make sure BRAM initialization occurs only once on the first reset. Subsequent resets should avoid re-configuring.

Proper use of debug module transaction controls for BRAM access can avoid issues with debug suspend. A JTAG probe with support for Cortex-M1 bus status indicators can also help identify bus errors.

Validation Approach

Validating correct reset and exception handling operation requires injecting faults to trigger errors. Potential validation techniques include:

• Simulate power on reset sequence and confirm proper boot.
• Introduce clock glitches to generate incorrect BRAM access timing.
• Toggle external BRAM reset pin during operation to corrupt state.
• Write invalid data to configuration registers to trigger exceptions.
• Enable MPU regions and simulate bus fault conditions.

Automated tests running on production boards can help validate robustness across temperature range, voltage levels, and noise conditions. Any latent bugs uncovered during validation should be addressed by adjustments to reset timing, debug configuration, or exception handling.

Conclusion

Using external BRAM with Cortex-M1 requires careful configuration of the reset sequence and timing. The processor needs to initialize the BRAM prior to executing code from the device. Proper reset handling and exception management will ensure a robust solution tolerant of faults and errors.

Following the guidance in this article will enable configuring the Cortex-M1 start-up reset behavior to successfully integrate and use external BRAM for program code or data storage. Proper validation allows confirmation of correct operation across all operating conditions.