0xBAAAAAAD address

Not all the peripheral memory can be accessed. Look at this program.

  1. #![no_main]
  2. #![no_std]
  4. use core::ptr;
  6. #[allow(unused_imports)]
  7. use aux7::{entry, iprint, iprintln};
  9. #[entry]
  10. fn main() -> ! {
  11.     aux7::init();
  13.     unsafe {
  14.         ptr::read_volatile(0x4800_1800 as *const u32);
  15.     }
  17.     loop {}
  18. }

This address is close to the GPIOE_BSRR address we used before but this address is invalid.Invalid in the sense that there’s no register at this address.

Now, let’s try it.

  1. $ cargo run
  2. Breakpoint 3, main () at src/07-registers/src/main.rs:9
  3. 9           aux7::init();
  5. (gdb) continue
  6. Continuing.
  8. Breakpoint 2, UserHardFault_ (ef=0x10001fc0)
  9.     at $REGISTRY/cortex-m-rt-0.6.3/src/lib.rs:535
  10. 535         loop {

We tried to do an invalid operation, reading memory that doesn’t exist, so the processor raised anexception, a hardware exception.

In most cases, exceptions are raised when the processor attempts to perform an invalid operation.Exceptions break the normal flow of a program and force the processor to execute an exceptionhandler, which is just a function/subroutine.

There are different kind of exceptions. Each kind of exception is raised by different conditions andeach one is handled by a different exception handler.

The aux7 crate depends on the cortex-m-rt crate which defines a defaulthard fault handler, named UserHardFault, that handles the “invalid memoryaddress” exception. openocd.gdb placed a breakpoint on HardFault; that’s whythe debugger halted your program while it was executing the exception handler.We can get more information about the exception from the debugger. Let’s see:

  1. (gdb) list
  2. 530
  3. 531     #[allow(unused_variables)]
  4. 532     #[doc(hidden)]
  5. 533     #[no_mangle]
  6. 534     pub unsafe extern "C" fn UserHardFault_(ef: &ExceptionFrame) -> ! {
  7. 535         loop {
  8. 536             // add some side effect to prevent this from turning into a UDF instruction
  9. 537             // see rust-lang/rust#28728 for details
  10. 538             atomic::compiler_fence(Ordering::SeqCst);
  11. 539         }

ef is a snapshot of the program state right before the exception occurred. Let’s inspect it:

  1. (gdb) print/x *ef
  2. $1 = cortex_m_rt::ExceptionFrame {
  3.   r0: 0x48001800,
  4.   r1: 0x48001800,
  5.   r2: 0xb,
  6.   r3: 0xc,
  7.   r12: 0xd,
  8.   lr: 0x800019f,
  9.   pc: 0x80028d6,
  10.   xpsr: 0x1000000
  11. }

There are several fields here but the most important one is pc, the Program Counter register.The address in this register points to the instruction that generated the exception. Let’sdisassemble the program around the bad instruction.

  1. (gdb) disassemble /m ef.pc
  2. Dump of assembler code for function core::ptr::read_volatile:
  3. 471     /checkout/src/libcore/ptr.rs: No such file or directory.
  4.    0x080028ce <+0>:     sub     sp, #16
  5.    0x080028d0 <+2>:     mov     r1, r0
  6.    0x080028d2 <+4>:     str     r0, [sp, #8]
  8. 472     in /checkout/src/libcore/ptr.rs
  9.    0x080028d4 <+6>:     ldr     r0, [sp, #8]
  10.    0x080028d6 <+8>:     ldr     r0, [r0, #0]
  11.    0x080028d8 <+10>:    str     r0, [sp, #12]
  12.    0x080028da <+12>:    ldr     r0, [sp, #12]
  13.    0x080028dc <+14>:    str     r1, [sp, #4]
  14.    0x080028de <+16>:    str     r0, [sp, #0]
  15.    0x080028e0 <+18>:    b.n     0x80028e2 <core::ptr::read_volatile+20>
  17. 473     in /checkout/src/libcore/ptr.rs
  18.    0x080028e2 <+20>:    ldr     r0, [sp, #0]
  19.    0x080028e4 <+22>:    add     sp, #16
  20.    0x080028e6 <+24>:    bx      lr
  22. End of assembler dump.

The exception was caused by the ldr r0, [r0, #0] instruction, a read instruction. The instructiontried to read the memory at the address indicated by the r0 register. By the way, r0 is a CPU(processor) register not a memory mapped register; it doesn’t have an associated address like, say,GPIO_BSRR.

Wouldn’t it be nice if we could check what the value of the r0 register was right at the instantwhen the exception was raised? Well, we already did! The r0 field in the ef value we printedbefore is the value of r0 register had when the exception was raised. Here it is again:

  1. (gdb) p/x *ef
  2. $1 = cortex_m_rt::ExceptionFrame {
  3.   r0: 0x48001800,
  4.   r1: 0x48001800,
  5.   r2: 0xb,
  6.   r3: 0xc,
  7.   r12: 0xd,
  8.   lr: 0x800019f,
  9.   pc: 0x80028d6,
  10.   xpsr: 0x1000000
  11. }

r0 contains the value 0x4800_1800 which is the invalid address we called the read_volatilefunction with.