CalvinBackup/Embedded-Hacking
1
0
Fork 0
mirror of https://github.com/mytechnotalent/Embedded-Hacking.git synced 2026-04-01 17:10:20 +02:00
Code Issues Packages Projects Releases Wiki Activity
Files
main
Embedded-Hacking/WEEK05/WEEK05.md
Kevin Thomas 612c0b5f3a Overhall w/ slides
2026-03-15 10:40:20 -04:00

59 KiB
Raw Permalink Blame History

Week 5: Integers and Floats in Embedded Systems: Debugging and Hacking Integers and Floats w/ Intermediate GPIO Output Assembler Analysis

🎯 What You'll Learn This Week

By the end of this tutorial, you will be able to:

  • Understand how integers and floating-point numbers are stored in memory
  • Know the difference between signed and unsigned integers (uint8_t vs int8_t)
  • Understand how floats and doubles are represented using IEEE 754 encoding
  • Use inline assembly to control GPIO pins directly at the hardware level
  • Debug numeric data types using GDB and the OpenOCD debugger
  • Hack integer values by modifying registers at runtime
  • Hack floating-point values by understanding and manipulating their binary representation
  • Reconstruct 64-bit doubles from two 32-bit registers

📚 Part 1: Understanding Integer Data Types

What is an Integer?

An integer is a whole number without any decimal point. Think of it like counting apples: you can have 0 apples, 1 apple, 42 apples, but you can't have 3.5 apples (that would be a fraction!).

In C programming for embedded systems, we have special integer types that tell the compiler exactly how much memory to use:

┌─────────────────────────────────────────────────────────────────┐
│  Integer Types - Different Sizes for Different Needs            │
│                                                                 │
│  uint8_t:  1 byte  (0 to 255)         - like a small box        │
│  int8_t:   1 byte  (-128 to 127)      - can hold negatives!     │
│  uint16_t: 2 bytes (0 to 65,535)      - medium box              │
│  uint32_t: 4 bytes (0 to 4 billion)   - big box                 │
│                                                                 │
└─────────────────────────────────────────────────────────────────┘

Signed vs Unsigned Integers

The difference between uint8_t and int8_t is whether the number can be negative:

Type Prefix Range Use Case
uint8_t u 0 to 255 Ages, counts, always positive
int8_t none -128 to 127 Temperature, can be negative

Let's review the code in 0x000b_integer-data-type.

#include <stdio.h>                          
#include "pico/stdlib.h"                   

int main(void) {                           
    uint8_t age = 43;                       
    int8_t range = -42;                     

    stdio_init_all();                     

    __asm volatile (                        
        "ldr r3, =0x40038000\n"             // address of PADS_BANK0_BASE
        "ldr r2, =0x40028004\n"             // address of IO_BANK0 GPIO0.ctrl
        "movs r0, #16\n"                    // GPIO16 (start pin)

        "init_loop:\n"                      // loop start
            "lsls r1, r0, #2\n"             // pin * 4 (pad offset)
            "adds r4, r3, r1\n"             // PADS base + offset
            "ldr  r5, [r4]\n"               // load current config
            "bic  r5, r5, #0x180\n"         // clear OD+ISO
            "orr  r5, r5, #0x40\n"          // set IE
            "str  r5, [r4]\n"               // store updated config

            "lsls r1, r0, #3\n"             // pin * 8 (ctrl offset)
            "adds r4, r2, r1\n"             // IO_BANK0 base + offset
            "ldr  r5, [r4]\n"               // load current config
            "bic  r5, r5, #0x1f\n"          // clear FUNCSEL bits [4:0]
            "orr  r5, r5, #5\n"             // set FUNCSEL = 5 (SIO)
            "str  r5, [r4]\n"               // store updated config

            "mov  r4, r0\n"                 // pin
            "movs r5, #1\n"                 // bit 1; used for OUT/OE writes
            "mcrr p0, #4, r4, r5, c4\n"     // gpioc_bit_oe_put(pin,1)
            "adds r0, r0, #1\n"             // increment pin
            "cmp  r0, #20\n"                // stop after pin 18
            "blt  init_loop\n"              // loop until r0 == 20
    );                              

    uint8_t pin = 16;                 

    while (1) {                     
        __asm volatile (                
            "mov r4, %0\n"                  // pin
            "movs r5, #0x01\n"              // bit 1; used for OUT/OE writes
            "mcrr p0, #4, r4, r5, c0\n"     // gpioc_bit_out_put(16, 1) 
            :
            : "r"(pin)
            : "r4","r5"
        );
        sleep_ms(500);                 

        __asm volatile (              
            "mov r4, %0\n"                  // pin
            "movs r5, #0\n"                 // bit 0; used for OUT/OE writes
            "mcrr p0, #4, r4, r5, c0\n"     // gpioc_bit_out_put(16, 0)
            :
            : "r"(pin)
            : "r4","r5"
        );
        sleep_ms(500);   

        pin++;                              
        if (pin > 18) pin = 16;            

        printf("age: %d\r\n", age);   
        printf("range: %d\r\n", range);
    }                                 
}

Breaking Down the Code

The Integer Variables

This program declares two integer variables that demonstrate the difference between signed and unsigned types:

uint8_t age = 43;
int8_t range = -42;

The variable age is a uint8_t — an unsigned 8-bit integer that can only hold values from 0 to 255. Since age is always a positive number, unsigned is the right choice. The variable range is an int8_t — a signed 8-bit integer that can hold values from -128 to 127. The signed type allows it to represent negative numbers like -42. Under the hood, negative values are stored using two's complement encoding: the CPU flips all the bits of 42 (0x2A) and adds 1, producing 0xD6, which is how -42 lives in a single byte of memory.

GPIO Initialization with Inline Assembly

Instead of using the Pico SDK's gpio_init(), gpio_set_dir(), and gpio_set_function() helpers, this program configures GPIO pins directly at the register level using inline assembly. This gives us a window into how the hardware actually works on the RP2350.

The initialization loop configures GPIO pins 16 through 19 (our red, green, blue, and yellow LEDs) in three steps per pin:

Step 1 — Configure the pad. Each GPIO pin has a pad control register in PADS_BANK0 starting at base address 0x40038000. The code calculates the offset as pin * 4, loads the current register value, clears the OD (output disable) and ISO (isolation) bits with bic r5, r5, #0x180, and sets the IE (input enable) bit with orr r5, r5, #0x40. This ensures the pad is electrically active and ready to drive output.

Step 2 — Set the pin function. Each GPIO pin has a control register in IO_BANK0 starting at 0x40028004. The offset is pin * 8 because each pin's control block is 8 bytes wide. The code clears the FUNCSEL field (bits [4:0]) and sets it to 5, which selects the SIO (Single-cycle I/O) function. SIO is the mode that lets software directly control pin state through the GPIO coprocessor.

Step 3 — Enable the output driver. The instruction mcrr p0, #4, r4, r5, c4 writes to the RP2350's GPIO coprocessor. Coprocessor register c4 controls the output enable — with r4 holding the pin number and r5 set to 1, this tells the hardware "this pin is an output." The mcrr (Move to Coprocessor from two ARM Registers) instruction is how the Cortex-M33 on the RP2350 talks to its dedicated GPIO coprocessor, bypassing the normal memory-mapped I/O path for single-cycle pin control.

The Blink Loop with Inline Assembly

Inside the while (1) loop, the program uses two inline assembly blocks to toggle the current LED on and off:

"mcrr p0, #4, r4, r5, c0\n"     // gpioc_bit_out_put(pin, 1)

This time the coprocessor register is c0 instead of c4. Register c0 controls the output value — setting r5 = 1 drives the pin HIGH (LED on), and r5 = 0 drives it LOW (LED off). Each toggle is followed by sleep_ms(500) for a half-second delay, creating a visible blink.

The GCC extended assembly syntax "r"(pin) tells the compiler to load the C variable pin into a general-purpose register and make it available as %0 inside the assembly block. The clobber list "r4","r5" warns the compiler that those registers are modified, so it won't store anything important there.

The Pin Cycling and Print Statements

After each on/off cycle, the program increments pin and wraps it back to 16 when it exceeds 18:

pin++;
if (pin > 18) pin = 16;

This cycles through GPIO 16, 17, and 18 — red, green, and blue LEDs — creating a rotating blink pattern. Finally, printf prints both integer variables over UART so we can observe their values on the serial terminal:

age: 43
range: -42

💡 Why use inline assembly instead of the SDK? This program is designed to teach you what happens beneath the SDK. When you call gpio_put(16, 1) in normal Pico code, the SDK ultimately does the same coprocessor write — mcrr p0, #4, r4, r5, c0. By writing the assembly directly, you can see exactly how the RP2350 hardware is controlled, which is essential knowledge for reverse engineering and binary patching.

📚 Part 2: Understanding Floating-Point Data Types

What is a Float?

A float is a number that can have a decimal point. Unlike integers which can only hold whole numbers like 42, a float can hold values like 42.5, 3.14, or -0.001. In C, the float type uses 32 bits (4 bytes) to store a number using the IEEE 754 standard.

┌─────────────────────────────────────────────────────────────────┐
│  IEEE 754 Single-Precision (32-bit float)                       │
│                                                                 │
│  ┌──────┬──────────┬───────────────────────────┐                │
│  │ Sign │ Exponent │ Mantissa (Fraction)       │                │
│  │ 1bit │  8 bits  │      23 bits              │                │
│  └──────┴──────────┴───────────────────────────┘                │
│                                                                 │
│  Value = (-1)^sign × 2^(exponent-127) × 1.mantissa              │
│                                                                 │
│  Example: 42.5                                                  │
│  Sign: 0 (positive)                                             │
│  Exponent: 10000100 (132 - 127 = 5)                             │
│  Mantissa: 01010100000000000000000                              │
│  Full: 0 10000100 01010100000000000000000                       │
│  Hex: 0x422A0000                                                │
│                                                                 │
└─────────────────────────────────────────────────────────────────┘

Float vs Integer - Key Differences

Property Integer (uint8_t) Float (float)
Size 1 byte 4 bytes
Precision Exact ~7 decimal digits
Range 0 to 255 ±3.4 × 10³⁸
Encoding Direct binary IEEE 754 (sign/exp/mantissa)
printf %d %f

Our Floating-Point Program

Let's look at a simple program that uses a float variable:

File: 0x000e_floating-point-data-type.c

#include <stdio.h>
#include "pico/stdlib.h"

int main(void) {
    float fav_num = 42.5;
    
    stdio_init_all();

    while (true)
        printf("fav_num: %f\r\n", fav_num);
}

What this code does:

  1. Declares a float variable fav_num and initializes it to 42.5
  2. Initializes the serial output
  3. Prints fav_num forever in a loop using the %f format specifier

💡 Why %f instead of %d? The %d format specifier tells printf to expect an integer. The %f specifier tells it to expect a floating-point number. Using the wrong one would print garbage!

Step 1: Flash the Binary to Your Pico 2

  1. Hold the BOOTSEL button on your Pico 2
  2. Plug in the USB cable (while holding BOOTSEL)
  3. Release BOOTSEL - a drive called "RPI-RP2" appears
  4. Drag and drop 0x000e_floating-point-data-type.uf2 onto the drive
  5. The Pico will reboot and start running!

Step 2: Verify It's Working

Open your serial monitor (PuTTY) and you should see:

You should see:

fav_num: 42.500000
fav_num: 42.500000
fav_num: 42.500000
...

The program is printing 42.500000 because printf with %f defaults to 6 decimal places.

🔬 Part 2.5: Setting Up Ghidra for Float Analysis

Step 3: Start Ghidra

Open a terminal and type:

ghidraRun

Ghidra will open. Now we need to create a new project.

Step 4: Create a New Project

  1. Click File → New Project
  2. Select Non-Shared Project
  3. Click Next
  4. Enter Project Name: 0x000e_floating-point-data-type
  5. Click Finish

Step 5: Import the Binary

  1. Open your file explorer
  2. Navigate to the Embedded-Hacking folder
  3. Find 0x000e_floating-point-data-type.bin
  4. Select Cortex M Little Endian 32
  5. Select Options and set up the .text and offset 10000000
  6. Drag and drop the .bin file into Ghidra's project window

Step 6: Configure the Binary Format

A dialog appears. The file is identified as a "BIN" (raw binary without debug symbols).

Click the three dots (…) next to "Language" and:

  1. Search for "Cortex"
  2. Select ARM Cortex 32 little endian default
  3. Click OK

Click the "Options…" button and:

  1. Change Block Name to .text
  2. Change Base Address to 10000000 (the XIP address!)
  3. Click OK

Step 7: Open and Analyze

  1. Double-click on the file in the project window
  2. A dialog asks "Analyze now?" - Click Yes
  3. Use default analysis options and click Analyze

Wait for analysis to complete (watch the progress bar in the bottom right).

🔬 Part 2.6: Navigating and Resolving Functions

Step 8: Find the Functions

Look at the Symbol Tree panel on the left. Expand Functions.

You'll see function names like:

  • FUN_1000019a
  • FUN_10000210
  • FUN_10000234

These are auto-generated names because we imported a raw binary without symbols!

Step 9: Resolve Known Functions

From our previous chapters, we know what some of these functions are:

Ghidra Name Actual Name How We Know
FUN_1000019a data_cpy From Week 3 boot analysis
FUN_10000210 frame_dummy From Week 3 boot analysis
FUN_10000234 main This is where our code is!

Step 10: Update Main's Signature

For main, let's also fix the return type:

  1. Right-click on main in the Decompile window
  2. Select Edit Function Signature
  3. Change to: int main(void)
  4. Click OK

🔬 Part 2.7: Analyzing the Main Function

Step 11: Examine Main in Ghidra

Click on main (or FUN_10000234). Look at the Decompile window:

You'll see something like:

int main(void)
{
  undefined4 uVar1;
  undefined4 extraout_r1;
  undefined4 uVar2;
  undefined4 extraout_r1_00;
  
  FUN_10002f5c();
  uVar1 = DAT_1000024c;
  uVar2 = extraout_r1;
  do {
    FUN_100030ec(DAT_10000250,uVar2,0,uVar1);
    uVar2 = extraout_r1_00;
  } while( true );
}

Step 12: Resolve stdio_init_all

  1. Click on FUN_10002f5c
  2. Right-click → Edit Function Signature
  3. Change to: bool stdio_init_all(void)
  4. Click OK

Step 13: Resolve printf

  1. Click on FUN_100030ec
  2. Right-click → Edit Function Signature
  3. Change to: int __wrap_printf(char *format,...)
  4. Check the Varargs checkbox (printf takes variable arguments!)
  5. Click OK

Step 14: Understand the Float Encoding

Look at the decompiled code after resolving functions:

int main(void)
{
  undefined4 uVar1;
  undefined4 extraout_r1;
  undefined4 uVar2;
  undefined4 extraout_r1_00;
  
  FUN_10002f5c();
  uVar1 = DAT_1000024c;
  uVar2 = extraout_r1;
  do {
    FUN_100030ec(DAT_10000250,uVar2,0,uVar1);
    uVar2 = extraout_r1_00;
  } while( true );
}

Where's float fav_num = 42.5? It's been optimized into an immediate value!

The compiler replaced our float variable with constants passed directly to printf. But wait — we see two values: 0x0, in r2 and DAT_1000024c or 0x40454000, in r3. That's because printf with %f always receives a double (64-bit), not a float (32-bit). The C standard requires that float arguments to variadic functions like printf are promoted to double.

A 64-bit double is passed in two 32-bit registers:

Register Value Role
r2 0x00000000 Low 32 bits
r3 0x40454000 High 32 bits

Together they form 0x40454000_00000000 — the IEEE 754 double-precision encoding of 42.5.

Step 15: Verify the Double Encoding

We need to decode 0x4045400000000000 field by field. The two registers give us the full 64-bit value:

r3 (high 32 bits): 0x40454000 = 0100 0000 0100 0101 0100 0000 0000 0000
r2 (low  32 bits): 0x00000000 = 0000 0000 0000 0000 0000 0000 0000 0000

Laid out as a single 64-bit value with every bit numbered:

Bit:    63  62-52 (11 bits)         51-32 (20 bits)                            31-0 (32 bits)
      ┌───┬───────────────────────┬──────────────────────────────────────────┬──────────────────────────────────┐
      │ 0 │ 1 0 0 0 0 0 0 0 1 0 0 │ 0 1 0 1 0 1 0 0 0 0 0 0 0  0 0 0 0 0 0 0 │ 00000000000000000000000000000000 │
      └───┴───────────────────────┴──────────────────────────────────────────┴──────────────────────────────────┘
       Sign     Exponent (11)              Mantissa high 20 bits                  Mantissa low 32 bits
                                           (from r3 bits 19–0)                    (from r2, all zero)

Step-by-step field extraction:

1. Sign bit

In IEEE 754, the sign bit is the very first (leftmost) bit of the 64-bit double. In the full 64-bit layout we call it bit 63:

64-bit double:  [bit 63] [bit 62 ... bit 0]
                    ^
                 sign bit

But we don't have a single 64-bit register — we have two 32-bit registers. The high register r3 holds bits 63–32 of the double. So bit 63 of the double is the same physical bit as bit 31 of r3 (the topmost bit of r3):

r3 holds bits 63–32 of the double
r2 holds bits 31–0  of the double

Now let's check it. IEEE 754 uses a simple rule for the sign bit:

Sign bit Meaning
0 Positive
1 Negative 
r3 = 0x40454000 = 0100 0000 0100 0101 0100 0000 0000 0000
                  ^
                  r3 bit 31 = 0  →  sign = 0  →  Positive number

The topmost bit of r3 is 0, so the number is positive. If that bit were 1 instead (e.g. 0xC0454000), the number would be negative (-42.5).

2. Exponent — bits 62–52 of the 64-bit value = bits 30–20 of r3

Extract bits 30–20 from 0x40454000:

0x40454000 in binary:  0      10000000100    01010100000000000000
                       sign   exponent       mantissa (top 20 bits)

Exponent bits: 10000000100

Convert to decimal: 2^{10} + 2^{2} = 1024 + 4 = 1028

But 1028 is not the actual power of 2 yet. IEEE 754 stores exponents with a bias — a fixed number that gets added during encoding so that the stored value is always positive (no sign bit needed for the exponent). For doubles, the bias is 1023.

💡 Why 1023? The exponent field is 11 bits wide, giving 2^{11} = 2048 total values. Half of that range should represent negative exponents and half positive. The midpoint is (2^{11} / 2) - 1 = 1023. So a stored exponent of 1023 means a real exponent of 0, values below 1023 are negative exponents, and values above 1023 are positive exponents.

To recover the real exponent, we subtract the bias:

\text{real exponent} = \text{stored exponent} - \text{bias} \text{real exponent} = 1028 - 1023 = \mathbf{5}

This means the number is scaled by 2^5 = 32. In other words, the mantissa gets shifted left by 5 binary places.

3. Mantissa — bits 51–0 of the 64-bit value

  • High 20 bits of mantissa (bits 51–32) = bits 19–0 of r3:
r3 bits 19–0:  0 1 0 1 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0
  • Low 32 bits of mantissa (bits 31–0) = all of r2:
r2 = 0x00000000  →  0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0

Full 52-bit mantissa:

0 1 0 1 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 | 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
  ← top 20 bits from r3 →                   ← bottom 32 bits from r2 (all zero) →

IEEE 754 always prepends an implied leading 1, so the actual value represented is:

1.010101 00000...  (the 1. is implicit, not stored)

4. Reconstruct the value

1.010101_2 \times 2^5

Shift the binary point 5 places right:

101010.1_2

Now convert each bit position to decimal:

Bit position Power of 2 Value
1 (bit 5) 2^5 32
0 (bit 4) 2^4 0
1 (bit 3) 2^3 8
0 (bit 2) 2^2 0
1 (bit 1) 2^1 2
0 (bit 0) 2^0 0
1 (bit −1) 2^{-1} 0.5
32 + 8 + 2 + 0.5 = \mathbf{42.5} ✓

Step 16: Examine the Assembly

Look at the Listing window (assembly view). Find the main function:

                             *************************************************************
                             *                           FUNCTION                          
                             *************************************************************
                             undefined  FUN_10000234 ()
             undefined         <UNASSIGNED>   <RETURN>
                             FUN_10000234+1                                  XREF[1,1]:   1000018c (c) , 1000018a (*)   
                             FUN_10000234
        10000234 38  b5           push       {r3,r4,r5,lr}
        10000236 02  f0  91  fe    bl         FUN_10002f5c                                     undefined FUN_10002f5c()
        1000023a 00  24           movs       r4,#0x0
        1000023c 03  4d           ldr        r5,[DAT_1000024c ]                               = 40454000h
                             LAB_1000023e                                    XREF[1]:     10000248 (j)   
        1000023e 22  46           mov        r2,r4
        10000240 2b  46           mov        r3,r5
        10000242 03  48           ldr        r0=>s_fav_num:_%f_100034a8 ,[DAT_10000250 ]       = "fav_num: %f\r\n"
                                                                                             = 100034A8h
        10000244 02  f0  52  ff    bl         FUN_100030ec                                     undefined FUN_100030ec()
        10000248 f9  e7           b          LAB_1000023e
        1000024a 00              ??         00h
        1000024b bf              ??         BFh
                             DAT_1000024c                                    XREF[1]:     FUN_10000234:1000023c (R)   
        1000024c 00  40  45  40    undefine   40454000h
                             DAT_10000250                                    XREF[1]:     FUN_10000234:10000242 (R)   
        10000250 a8  34  00  10    undefine   100034A8h                                        ?  ->  100034a8

🎯 Key Insight: The mov.w r2, #0x0 loads the low 32 bits (all zeros) and ldr r3, [DAT_...] loads the high 32 bits (0x40454000) of the double. Together, r2:r3 = 0x40454000_00000000 = 42.5 as a double.

Step 17: Find the Format String

In the Listing view, click on the data reference to find the format string:

                             s_fav_num:_%f_100034a8                          XREF[1]:     FUN_10000234:10000242 (*)   
        100034a8 66  61  76       ds         "fav_num: %f\r\n"
                 5f  6e  75 
                 6d  3a  20

This confirms printf is called with the format string "fav_num: %f\r\n" and the double-precision value of 42.5.

🔬 Part 2.8: Patching the Float - Changing 42.5 to 99.0

Step 18: Calculate the New IEEE 754 Encoding

We want to change 42.5 to 99.0. First, we need to figure out the double-precision encoding of 99.0:

Step A — Convert the integer part (99) to binary:

Division Quotient Remainder
99 ÷ 2 49 1
49 ÷ 2 24 1
24 ÷ 2 12 0
12 ÷ 2 6 0
6 ÷ 2 3 0
3 ÷ 2 1 1
1 ÷ 2 0 1

Read remainders bottom-to-top: 99_{10} = 1100011_2

Step B — Convert the fractional part (.0) to binary:

There is no fractional part — .0 is exactly zero, so the fractional binary is just 0.

Step C — Combine:

99.0_{10} = 1100011.0_2

Step D — Normalize to IEEE 754 form (move the binary point so there's exactly one 1 before it):

1100011.0_2 = 1.100011_2 \times 2^6

We shifted the binary point 6 places left, so the exponent is 6.

Step E — Extract the IEEE 754 fields:

  1. Sign: 0 (positive)
  2. Exponent: 6 + 1023 = 1029 = 10000000101_2
  3. Mantissa: 1000110000000000... (everything after the 1., padded with zeros to 52 bits)
  4. Full double: 0x4058C00000000000
Register Old Value New Value
r2 0x00000000 0x00000000
r3 0x40454000 0x4058C000

Since r2 stays 0x00000000, we only need to patch the high word loaded into r3.

Step 19: Find the Value to Patch

Look in the Listing view for the data that loads the high word of the double:

        10000248 00  40  45  40   undefined4  40454000h

This is the 32-bit constant that gets loaded into r3 — the high word of our double 42.5.

Step 20: Patch the Constant

  1. Click on Window -> Bytes
  2. Click on Pencil Icon in Bytes Editor
  3. Right-click and select Patch Data
  4. Change 00404540 to 00C05840
  5. Press Enter

This changes the high word from 0x40454000 (42.5 as double) to 0x4058C000 (99.0 as double).

🔬 Part 2.9: Export and Test the Hacked Binary

Step 21: Export the Patched Binary

  1. Click File → Export Program
  2. Set Format to Raw Bytes
  3. Navigate to your build directory
  4. Name the file 0x000e_floating-point-data-type-h.bin
  5. Click OK

Step 22: Convert to UF2 Format

Open a terminal and navigate to your project directory:

cd C:\Users\flare-vm\Desktop\Embedded-Hacking-main\0x000e_floating-point-data-type

Run the conversion command:

python ..\uf2conv.py build\0x000e_floating-point-data-type-h.bin --base 0x10000000 --family 0xe48bff59 --output build\hacked.uf2

Step 23: Flash the Hacked Binary

  1. Hold BOOTSEL and plug in your Pico 2
  2. Drag and drop hacked.uf2 onto the RPI-RP2 drive
  3. Open your serial monitor

You should see:

fav_num: 99.000000
fav_num: 99.000000
fav_num: 99.000000
...

🎉 BOOM! We hacked the float! The value changed from 42.5 to 99.0!

📚 Part 3: Understanding Double-Precision Floating-Point Data Types

What is a Double?

A double (short for "double-precision floating-point") is like a float but with twice the precision. While a float uses 32 bits, a double uses 64 bits (8 bytes), giving it roughly 15–16 significant decimal digits of precision compared to a float's ~7.

┌─────────────────────────────────────────────────────────────────┐
│  IEEE 754 Double-Precision (64-bit double)                      │
│                                                                 │
│  ┌──────┬───────────┬──────────────────────────────────────┐    │
│  │ Sign │ Exponent  │ Mantissa (Fraction)                  │    │
│  │ 1bit │  11 bits  │      52 bits                         │    │
│  └──────┴───────────┴──────────────────────────────────────┘    │
│                                                                 │
│  Value = (-1)^sign × 2^(exponent-1023) × 1.mantissa             │
│                                                                 │
│  Example: 42.52525                                              │
│  Sign: 0 (positive)                                             │
│  Exponent: 10000000100 (1028 - 1023 = 5)                        │
│  Mantissa: 0101010000110011101101100100010110100001110010101100 │
│  Hex: 0x4045433B645A1CAC                                        │
│                                                                 │
└─────────────────────────────────────────────────────────────────┘

Float vs Double - Key Differences

Property Float (float) Double (double)
Size 4 bytes (32 bits) 8 bytes (64 bits)
Precision ~7 decimal digits ~15 decimal digits
Exponent 8 bits (bias 127) 11 bits (bias 1023)
Mantissa 23 bits 52 bits
Range ±3.4 × 10³⁸ ±1.8 × 10³⁰⁸
printf %f %lf
ARM passing Promoted to double Native in r2:r3

💡 Why does precision matter? With a float, the value 42.52525 might be stored as 42.525249 due to rounding. A double can represent it as 42.525250 with much higher fidelity. For scientific or financial applications, that extra precision is critical!

Our Double-Precision Program

Let's look at a program that uses a double variable:

File: 0x0011_double-floating-point-data-type.c

#include <stdio.h>
#include "pico/stdlib.h"

int main(void) {
    double fav_num = 42.52525;
    
    stdio_init_all();

    while (true)
        printf("fav_num: %lf\r\n", fav_num);
}

What this code does:

  1. Declares a double variable fav_num and initializes it to 42.52525
  2. Initializes the serial output
  3. Prints fav_num forever in a loop using the %lf format specifier

💡 %lf vs %f: While printf actually treats %f and %lf identically (both expect a double), using %lf makes your intent clear — you're explicitly working with a double, not a float. It's good practice to match the format specifier to your variable type.

Step 1: Flash the Binary to Your Pico 2

  1. Hold the BOOTSEL button on your Pico 2
  2. Plug in the USB cable (while holding BOOTSEL)
  3. Release BOOTSEL - a drive called "RPI-RP2" appears
  4. Drag and drop 0x000A_intro-to-doubles.uf2 onto the drive
  5. The Pico will reboot and start running!

Step 2: Verify It's Working

Open your serial monitor (PuTTY) and you should see:

You should see:

fav_num: 42.525250
fav_num: 42.525250
fav_num: 42.525250
...

The program is printing 42.525250 because printf with %lf defaults to 6 decimal places.

🔬 Part 3.5: Setting Up Ghidra for Double Analysis

Step 3: Start Ghidra

Open a terminal and type:

ghidraRun

Ghidra will open. Now we need to create a new project.

Step 4: Create a New Project

  1. Click File → New Project
  2. Select Non-Shared Project
  3. Click Next
  4. Enter Project Name: 0x000A_intro-to-doubles
  5. Click Finish

Step 5: Import the Binary

  1. Open your file explorer
  2. Navigate to the Embedded-Hacking folder
  3. Find 0x0011_double-floating-point-data-type.bin
  4. Select Cortex M Little Endian 32
  5. Select Options and set up the .text and offset 10000000
  6. Drag and drop the .bin file into Ghidra's project window

Step 6: Configure the Binary Format

A dialog appears. The file is identified as a "BIN" (raw binary without debug symbols).

Click the three dots (…) next to "Language" and:

  1. Search for "Cortex"
  2. Select ARM Cortex 32 little endian default
  3. Click OK

Click the "Options…" button and:

  1. Change Block Name to .text
  2. Change Base Address to 10000000 (the XIP address!)
  3. Click OK

Step 7: Open and Analyze

  1. Double-click on the file in the project window
  2. A dialog asks "Analyze now?" - Click Yes
  3. Use default analysis options and click Analyze

Wait for analysis to complete (watch the progress bar in the bottom right).

🔬 Part 3.6: Navigating and Resolving Functions

Step 8: Find the Functions

Look at the Symbol Tree panel on the left. Expand Functions.

You'll see function names like:

  • FUN_1000019a
  • FUN_10000210
  • FUN_10000238

These are auto-generated names because we imported a raw binary without symbols!

Step 9: Resolve Known Functions

From our previous chapters, we know what some of these functions are:

Ghidra Name Actual Name How We Know
FUN_1000019a data_cpy From Week 3 boot analysis
FUN_10000210 frame_dummy From Week 3 boot analysis
FUN_10000238 main This is where our code is!

Step 10: Update Main's Signature

For main, let's also fix the return type:

  1. Right-click on main in the Decompile window
  2. Select Edit Function Signature
  3. Change to: int main(void)
  4. Click OK

🔬 Part 3.7: Analyzing the Main Function

Step 11: Examine Main in Ghidra

Click on main (or FUN_10000234). Look at the Decompile window:

You'll see something like:

void FUN_10000238(void)
{
  undefined4 uVar1;
  undefined4 uVar2;
  undefined4 extraout_r1;
  undefined4 uVar3;
  undefined4 extraout_r1_00;
  undefined4 in_r3;
  
  uVar2 = DAT_10000258;
  uVar1 = DAT_10000254;
  FUN_10002f64();
  uVar3 = extraout_r1;
  do {
    FUN_100030f4(DAT_10000250,uVar3,uVar1,uVar2,in_r3);
    uVar3 = extraout_r1_00;
  } while( true );
}

Step 12: Resolve stdio_init_all

  1. Click on FUN_10002f64
  2. Right-click → Edit Function Signature
  3. Change to: bool stdio_init_all(void)
  4. Click OK

Step 13: Resolve printf

  1. Click on FUN_100030f4
  2. Right-click → Edit Function Signature
  3. Change the name to printf
  4. Check the Varargs checkbox (printf takes variable arguments!)
  5. Click OK

Step 14: Understand the Double Encoding

Look at the decompiled code after resolving functions:

int main(void)
{
  undefined4 uVar1;
  undefined4 uVar2;
  undefined4 extraout_r1;
  undefined4 uVar3;
  undefined4 extraout_r1_00;
  
  uVar2 = DAT_10000258;
  uVar1 = DAT_10000254;
  FUN_10002f64();
  uVar3 = extraout_r1;
  do {
    FUN_100030f4(DAT_10000250,uVar3,uVar1,uVar2);
    uVar3 = extraout_r1_00;
  } while( true );
}

Where's double fav_num = 42.52525? It's been optimized into immediate values!

This time we see two non-zero values: 0x645a1cac and 0x4045433b. Unlike the float example where the low word was 0x0, a double with a fractional part like 42.52525 needs all 52 mantissa bits — so both halves carry data.

A 64-bit double is passed in two 32-bit registers:

Register Value Role
r2 0x645A1CAC Low 32 bits
r3 0x4045433B High 32 bits

Together they form 0x4045433B645A1CAC — the IEEE 754 double-precision encoding of 42.52525.

🎯 Key Difference from Float: In the float example, r2 was 0x00000000 because 42.5 has a clean fractional part. But 42.52525 has a repeating binary fraction, so the low 32 bits are non-zero (0x645A1CAC). This means both registers matter when patching doubles with complex fractional values!

Step 15: Verify the Double Encoding

We need to decode 0x4045433B645A1CAC field by field. The two registers give us the full 64-bit value:

r3 (high 32 bits): 0x4045433B = 0100 0000 0100 0101 0100 0011 0011 1011
r2 (low  32 bits): 0x645A1CAC = 0110 0100 0101 1010 0001 1100 1010 1100

Laid out as a single 64-bit value with every bit numbered:

Bit:    63  62-52 (11 bits)         51-32 (20 bits)                            31-0 (32 bits)
      ┌───┬───────────────────────┬──────────────────────────────────────────┬──────────────────────────────────────────┐
      │ 0 │ 1 0 0 0 0 0 0 0 1 0 0 │ 0 1 0 1 0 1 0 0 0 0 1 1 0 0 1 1 1 0 1 1  │ 01100100010110100001110010101100         │
      └───┴───────────────────────┴──────────────────────────────────────────┴──────────────────────────────────────────┘
       Sign     Exponent (11)              Mantissa high 20 bits                  Mantissa low 32 bits
                                           (from r3 bits 19–0)                    (from r2)

🎯 Key Difference from 42.5: In the 42.5 example, r2 was 0x00000000 because 42.5 has a clean fractional part (.5 = exactly one binary digit). But 42.52525 has a repeating binary fraction, so the low 32 bits are non-zero (0x645A1CAC). Every bit of both registers matters here!

Step-by-step field extraction:

1. Sign bit

The sign bit is bit 63 of the 64-bit double, which is bit 31 of r3 (the high register holds bits 63–32):

r3 = 0x4045433B = 0100 0000 0100 0101 0100 0011 0011 1011
                  ^
                  r3 bit 31 = 0  →  sign = 0  →  Positive number ✓

2. Exponent — bits 62–52 = bits 30–20 of r3

Extract bits 30–20 from 0x4045433B:

0x4045433B in binary:  0      10000000100    01010100001100111011
                       sign   exponent       mantissa (top 20 bits)

Exponent bits: 10000000100

Convert to decimal: 2^{10} + 2^{2} = 1024 + 4 = 1028

Subtract the bias (same formula as Part 2 — the bias is 1023 for all doubles):

\text{real exponent} = 1028 - 1023 = \mathbf{5}

This means the mantissa gets shifted left by 5 binary places (i.e. multiplied by 2^5 = 32).

3. Mantissa — bits 51–0

Unlike the 42.5 example where r2 was all zeros, both registers contribute non-zero bits here:

  • High 20 bits of mantissa (bits 51–32) = bits 19–0 of r3:
r3 bits 19–0:  0 1 0 1 0 1 0 0 0 0 1 1 0 0 1 1 1 0 1 1
  • Low 32 bits of mantissa (bits 31–0) = all of r2:
r2 = 0x645A1CAC  →  0 1 1 0 0 1 0 0 0 1 0 1 1 0 1 0 0 0 0 1 1 1 0 0 1 0 1 0 1 1 0 0

Full 52-bit mantissa:

0 1 0 1 0 1 0 0 0 0 1 1 0 0 1 1 1 0 1 1 | 0 1 1 0 0 1 0 0 0 1 0 1 1 0 1 0 0 0 0 1 1 1 0 0 1 0 1 0 1 1 0 0
  ← top 20 bits from r3 →                   ← bottom 32 bits from r2 →

IEEE 754 always prepends an implied leading 1, so the actual value represented is:

1.0101010000110011101101100100010110100001110010101100  (the 1. is implicit, not stored)

4. Reconstruct the value

1.0101010000110011101101100100..._2 \times 2^5

Shift the binary point 5 places right:

101010.10000110011101101100100010110100001110010101100_2

Integer part (101010):

Bit position Power of 2 Value
1 (bit 5) 2^5 32
0 (bit 4) 2^4 0
1 (bit 3) 2^3 8
0 (bit 2) 2^2 0
1 (bit 1) 2^1 2
0 (bit 0) 2^0 0
32 + 8 + 2 = \mathbf{42}

Fractional part (.10000110011101101...):

Bit position Power of 2 Decimal value
1 (bit −1) 2^{-1} 0.5
0 (bit −2) 2^{-2} 0
0 (bit −3) 2^{-3} 0
0 (bit −4) 2^{-4} 0
0 (bit −5) 2^{-5} 0
1 (bit −6) 2^{-6} 0.015625
1 (bit −7) 2^{-7} 0.0078125
0 (bit −8) 2^{-8} 0
0 (bit −9) 2^{-9} 0
1 (bit −10) 2^{-10} 0.0009765625
1 (bit −11) 2^{-11} 0.00048828125
1 (bit −12) 2^{-12} 0.000244140625
... ... (remaining 35 bits add smaller and smaller fractions)

First 12 fractional bits sum: 0.5 + 0.015625 + 0.0078125 + 0.0009765625 + 0.00048828125 + 0.000244140625 \approx 0.5251

The remaining 35 fractional bits refine this to \approx 0.52525. This is because 0.52525 is a repeating fraction in binary — it can never be represented with a finite number of bits, so double precision stores the closest possible 52-bit approximation.

42 + 0.52525 = \mathbf{42.52525} ✓

Step 16: Examine the Assembly

Look at the Listing window (assembly view). Find the main function:

                             *************************************************************
                             *                           FUNCTION                          
                             *************************************************************
                             undefined  FUN_10000238 ()
             undefined         <UNASSIGNED>   <RETURN>
                             FUN_10000238+1                                  XREF[1,1]:   1000018c (c) , 1000018a (*)   
                             FUN_10000238
        10000238 38  b5           push       {r3,r4,r5,lr}
        1000023a 06  a5           adr        r5,[0x10000254 ]
        1000023c d5  e9  00  45    ldrd       r4,r5,[r5,#0x0 ]=>DAT_10000254                   = 645A1CACh
                                                                                             = 4045433Bh
        10000240 02  f0  90  fe    bl         FUN_10002f64                                     undefined FUN_10002f64()
                             LAB_10000244                                    XREF[1]:     1000024e (j)   
        10000244 22  46           mov        r2,r4
        10000246 2b  46           mov        r3,r5
        10000248 01  48           ldr        r0=>s_fav_num:_%lf_100034b0 ,[DAT_10000250 ]      = "fav_num: %lf\r\n"
                                                                                             = 100034B0h
        1000024a 02  f0  53  ff    bl         FUN_100030f4                                     undefined FUN_100030f4()
        1000024e f9  e7           b          LAB_10000244
                             DAT_10000250                                    XREF[1]:     FUN_10000238:10000248 (R)   
        10000250 b0  34  00  10    undefine   100034B0h                                        ?  ->  100034b0
                             DAT_10000254                                    XREF[1]:     FUN_10000238:1000023c (R)   
        10000254 ac  1c  5a  64    undefine   645A1CACh
                             DAT_10000258                                    XREF[1]:     FUN_10000238:1000023c (R)   
        10000258 3b  43  45  40    undefine   4045433Bh

🎯 Key Insight: Notice that both r2 and r3 are loaded from data constants using ldr. Compare this to the float example where r2 was loaded with mov.w r2, #0x0. Because 42.52525 requires all 52 mantissa bits, neither word can be zero — the compiler must store both halves as separate data constants.

Step 17: Find the Format String

In the Listing view, click on the data reference to find the format string:

                             s_fav_num:_%lf_100034b0                         XREF[1]:     FUN_10000238:10000248 (*)   
        100034b0 66  61  76       ds         "fav_num: %lf\r\n"
                 5f  6e  75 
                 6d  3a  20

This confirms printf is called with the format string "fav_num: %lf\r\n" and the double-precision value of 42.52525.

🔬 Part 3.8: Patching the Double - Changing 42.52525 to 99.99

Step 18: Calculate the New IEEE 754 Encoding

We want to change 42.52525 to 99.99. First, we need to figure out the double-precision encoding of 99.99:

  1. 99.99 = 1.5623... \times 2^6 = 1.100011111111..._2 \times 2^6
  2. Sign: 0 (positive)
  3. Exponent: 6 + 1023 = 1029 = 10000000101_2
  4. Mantissa: `1000111111010111000010100011110101110000101000111..._2$
  5. Full double: 0x4058FF5C28F5C28F
Register Old Value New Value
r2 0x645A1CAC 0x28F5C28F
r3 0x4045433B 0x4058FF5C

Unlike the float example, both registers change! The value 99.99 has a repeating binary fraction, so both the high and low words are different.

Step 19: Find the Values to Patch

Look in the Listing view for the two data constants:

Low word (loaded into r2):

        10000254 ac  1c  5a  64   undefined4  645A1CACh

High word (loaded into r3):

        10000258 3b  43  45  40   undefined4  4045433Bh

Step 20: Patch Both Constants

Patch the low word:

  1. Click on the data at address 10000254 containing 645A1CAC
  2. Right-click and select Patch Data
  3. Change 645A1CAC to 28F5C28F -> 8FC2F528
  4. Press Enter

Patch the high word:

  1. Click on the data at address 10000258 containing 4045433B
  2. Right-click and select Patch Data
  3. Change 4045433B to 4058FF5C -> 5CFF5840
  4. Press Enter

This changes the full 64-bit double from 0x4045433B645A1CAC (42.52525) to 0x4058FF5C28F5C28F (99.99).

🎯 Key Difference from Float Patching: When we patched the float 42.5, we only needed to change one word (the high word in r3) because the low word was all zeros. With 42.52525 → 99.99, both words change. Always check whether the low word is non-zero before patching!

🔬 Part 3.9: Export and Test the Hacked Binary

Step 21: Export the Patched Binary

  1. Click File → Export Program
  2. Set Format to Raw Bytes
  3. Navigate to your build directory
  4. Name the file 0x0011_double-floating-point-data-type-h.bin
  5. Click OK

Step 22: Convert to UF2 Format

Open a terminal and navigate to your project directory:

cd C:\Users\flare-vm\Desktop\Embedded-Hacking-main\0x0011_double-floating-point-data-type

Run the conversion command:

python ..\uf2conv.py build\0x0011_double-floating-point-data-type-h.bin --base 0x10000000 --family 0xe48bff59 --output build\hacked.uf2

Step 23: Flash the Hacked Binary

  1. Hold BOOTSEL and plug in your Pico 2
  2. Drag and drop hacked.uf2 onto the RPI-RP2 drive
  3. Open your serial monitor

You should see:

fav_num: 99.990000
fav_num: 99.990000
fav_num: 99.990000
...

🎉 BOOM! We hacked the double! The value changed from 42.52525 to 99.99!

📊 Part 3.95: Summary - Float and Double Analysis

What We Accomplished

  1. Learned about IEEE 754 - How floating-point numbers are encoded in 32-bit (float) and 64-bit (double) formats
  2. Discovered float-to-double promotion - printf with %f always receives a double, even when you pass a float
  3. Decoded register pairs - 64-bit doubles are split across r2 (low) and r3 (high)
  4. Patched a float value - Changed 42.5 to 99.0 by modifying only the high word
  5. Patched a double value - Changed 42.52525 to 99.99 by modifying both words
  6. Understood the key difference - Clean fractions (like 42.5) have a zero low word; complex fractions (like 42.52525) require patching both words

IEEE 754 Quick Reference for Common Values

Value Double Hex High Word (r3) Low Word (r2)
42.0 0x4045000000000000 0x40450000 0x00000000
42.5 0x4045400000000000 0x40454000 0x00000000
42.52525 0x4045433B645A1CAC 0x4045433B 0x645A1CAC
43.0 0x4045800000000000 0x40458000 0x00000000
99.0 0x4058C00000000000 0x4058C000 0x00000000
99.99 0x4058FF5C28F5C28F 0x4058FF5C 0x28F5C28F
100.0 0x4059000000000000 0x40590000 0x00000000
3.14 0x40091EB851EB851F 0x40091EB8 0x51EB851F

The Float/Double Patching Workflow

┌─────────────────────────────────────────────────────────────────┐
│  1. Identify the float/double value in the decompiled view      │
│     - Look for hex constants like 0x40454000 or 0x4045433B      │
├─────────────────────────────────────────────────────────────────┤
│  2. Determine if it's float (32-bit) or double (64-bit)         │
│     - printf promotes floats to doubles!                        │
│     - Check if value spans r2:r3 (double) or just r0 (float)    │
├─────────────────────────────────────────────────────────────────┤
│  3. Check if the low word (r2) is zero or non-zero              │
│     - Zero low word = only patch the high word                  │
│     - Non-zero low word = patch BOTH words                      │
├─────────────────────────────────────────────────────────────────┤
│  4. Calculate the new IEEE 754 encoding                         │
│     - Convert your desired value to IEEE 754                    │
│     - Split into high/low words                                 │
├─────────────────────────────────────────────────────────────────┤
│  5. Patch the constant(s) in Ghidra                             │
│     - Right-click → Patch Data                                  │
│     - Replace the old encoding with the new one                 │
├─────────────────────────────────────────────────────────────────┤
│  6. Export → Convert to UF2 → Flash → Verify                    │
│     - Same workflow as integer patching                         │
└─────────────────────────────────────────────────────────────────┘

💡 Key takeaway: Hacking doubles is the same process as hacking floats — find the IEEE 754 constant, calculate the new encoding, patch it. The only extra step is checking whether the low word (r2) is also non-zero. Clean values like 42.5 only need one patch; messy fractions like 42.52525 need two!

✅ Practice Exercises

Exercise 1: Patch the Float to Pi

The float program stores 42.5. Patch it in Ghidra so the serial output prints 3.14 instead.

Hint: 3.14 as a double is 0x40091EB851EB851F — the high word is 0x40091EB8 and the low word is 0x51EB851F. You'll need to patch both words since the low word is non-zero!

Exercise 2: Patch the Double to a Whole Number

The double program stores 42.52525. Instead of patching it to 99.99 (as we did in the chapter), patch it to 100.0.

Hint: 100.0 as a double is 0x4059000000000000 — high word 0x40590000, low word 0x00000000. Notice the low word is all zeros this time — but the original low word (0x645A1CAC) is non-zero, so you still need to patch it to 0x00000000!

Exercise 3: Change the Blink Speed

The LED blinks every 500ms. Find the sleep_ms(500) calls in the binary and change them to sleep_ms(100) for faster blinking.

Hint: Look for the value 0x1F4 (500 in hex) being loaded into a register before the delay call.

Exercise 4: Find the Format Strings

Both programs use format strings ("fav_num: %f\r\n" and "fav_num: %lf\r\n"). Can you find these strings in Ghidra and determine where they're stored?

Hint: Look in the .rodata section. Try pressing S in Ghidra to search for strings, or navigate to addresses near 0x10003xxx.

🎓 Key Takeaways

  1. Integers have fixed sizes - uint8_t is 1 byte (0–255), int8_t is 1 byte (-128 to 127). The u prefix means unsigned.

  2. IEEE 754 encodes floats in binary - Sign bit, exponent (with bias), and mantissa form the encoding for both 32-bit floats and 64-bit doubles.

  3. printf promotes floats to doubles - Even when you pass a float, printf receives a 64-bit double due to C's variadic function rules.

  4. 64-bit values span two registers - On ARM Cortex-M33, doubles use r2 (low 32 bits) and r3 (high 32 bits).

  5. Clean fractions have zero low words - Values like 42.5 have 0x00000000 in the low word; complex fractions like 42.52525 have non-zero low words.

  6. Inline assembly controls hardware directly - The mcrr coprocessor instruction talks to the GPIO block without any SDK overhead.

  7. Binary patching works on any data type - Integers, floats, and doubles can all be patched in Ghidra using the same workflow.

📖 Glossary

Term Definition
Bias Constant added to the exponent in IEEE 754 (127 for float, 1023 for double)
Double 64-bit floating-point type following IEEE 754 double-precision format
Exponent Part of IEEE 754 encoding that determines the magnitude of the number
Float 32-bit floating-point type following IEEE 754 single-precision format
FUNCSEL Function Select - register field that assigns a GPIO pin's function (e.g., SIO)
GPIO General Purpose Input/Output - controllable pins on a microcontroller
IEEE 754 International standard for floating-point arithmetic and binary encoding
Inline Assembly Assembly code embedded directly within C source using __asm volatile
int8_t Signed 8-bit integer type (-128 to 127)
IO_BANK0 Register block at 0x40028000 that controls GPIO pin function selection
Mantissa Fractional part of IEEE 754 encoding (23 bits for float, 52 bits for double)
mcrr ARM coprocessor register transfer instruction used for GPIO control
PADS_BANK0 Register block at 0x40038000 that controls GPIO pad electrical properties
Promotion Automatic conversion of a smaller type to a larger type (float → double)
Register Pair Two 32-bit registers (r2:r3) used together to hold a 64-bit value
UF2 USB Flashing Format - file format for Pico 2 firmware
uint8_t Unsigned 8-bit integer type (0 to 255)

🔗 Additional Resources

GPIO Coprocessor Reference

The RP2350 GPIO coprocessor instructions:

Instruction Description
mcrr p0, #4, Rt, Rt2, c0 Set/clear GPIO output
mcrr p0, #4, Rt, Rt2, c4 Set/clear GPIO output enable

RP2350 Memory Map Quick Reference

Address Description
0x10000000 XIP Flash (code)
0x20000000 SRAM (data)
0x40028000 IO_BANK0 (GPIO control)
0x40038000 PADS_BANK0 (pad control)
0xd0000000 SIO (single-cycle I/O)

IEEE 754 Encoding Formula

┌─────────────────────────────────────────────────────────────────┐
│  Float (32-bit):   [1 sign] [8 exponent] [23 mantissa]          │
│  Double (64-bit):  [1 sign] [11 exponent] [52 mantissa]         │
│                                                                 │
│  Value = (-1)^sign × 2^(exponent - bias) × (1 + mantissa)       │
│                                                                 │
│  Float bias:  127                                               │
│  Double bias: 1023                                              │
└─────────────────────────────────────────────────────────────────┘

Remember: Every binary you encounter in the real world can be analyzed and understood using these same techniques. Whether it's an integer, a float, or a double — it's all just bits waiting to be decoded. Practice makes perfect!

Happy hacking! 🔧

Reference in New Issue View Git Blame Copy Permalink