Skip to content

feat: re-add IAP flash profile storage using LPC2134 sector 7#7

Merged
ImNoahDev merged 10 commits into
masterfrom
IAP
Mar 22, 2026
Merged

feat: re-add IAP flash profile storage using LPC2134 sector 7#7
ImNoahDev merged 10 commits into
masterfrom
IAP

Conversation

@ImNoahDev
Copy link
Copy Markdown
Collaborator

Store up to 32 reflow profiles in flash sector 7 (8KB at 0xE000). The linker splits firmware across MFlash_Lo (sectors 0-6, 56KB) and MFlash_Hi (sectors 8-10, 64KB) for 120KB total firmware space.

Uses cache-erase-rewrite pattern with ~3.7KB static BSS cache. IAP calls use correct sector 7 (not nonexistent sector 19 as before).

Serial commands: save flash, delete flash, list flash, backup. All commands identical to the v2.1.0 interface.

Store up to 32 reflow profiles in flash sector 7 (8KB at 0xE000).
The linker splits firmware across MFlash_Lo (sectors 0-6, 56KB) and
MFlash_Hi (sectors 8-10, 64KB) for 120KB total firmware space.

Uses cache-erase-rewrite pattern with ~3.7KB static BSS cache.
IAP calls use correct sector 7 (not nonexistent sector 19 as before).

Serial commands: save flash, delete flash, list flash, backup.
All commands identical to the v2.1.0 interface.
Sector 7 split failed: MFlash_Hi was 64KB, firmware is 94KB.
Sector 10 works but only gives 96KB firmware.

Sector 1 (0x2000-0x3FFF, 8KB) is optimal:
- MFlash_Vec (sector 0, 8KB): vectors, section table, CRP, startup
- Sector 1: 32 profile slots × 256 bytes
- MFlash_Code (sectors 2-10, 112KB): main .text, .rodata, .data LMA

Firmware gets 120KB total. 94KB code fits in 112KB MFlash_Code
with 18KB to spare.
The IAP write was failing because iap_prepare_sector() was a separate
function that re-enabled IRQs after prepare. Any interrupt between
prepare and the copy/erase would invalidate the preparation.

Now prepare and execute happen in a single IRQ-disabled critical
section for both erase and write operations.

Also fixed rewrite_sector to return -1 when the target slot write
fails, so the caller correctly reports errors.
Print NXP IAP status codes on failure:
0=OK, 7=INVALID_SECTOR, 8=NOT_BLANK, 9=NOT_PREPARED, etc.
Also shows sector number and base address at init.
The LPC2134 IAP ROM uses 0x40003FE0-0x40003FFF to store state
(e.g. which sector is prepared). The stack started at 0x40004000
and grew down into this area, overwriting the IAP's 'sector prepared'
state between prepare and copy calls — causing IAP code 9
(SECTOR_NOT_PREPARED_FOR_WRITE_OPERATION).

Fix: shrink Ram16 by 32 bytes so the stack top is 0x40003FE0,
keeping the IAP workspace safe.
Previous 32-byte reservation was insufficient. UM10120 states:
'The top 256 bytes of on-chip RAM are reserved and used by the
ISP/IAP handler' for LPC2131/32/34/36/38.

Stack top moves from 0x40003FE0 to 0x40003F00, fully clearing
the IAP workspace at 0x40003F00-0x40003FFF.
UM10120: 'When flash programming is performed, it is recommended
that MAM be disabled.' The MAM caches flash reads and interferes
with IAP flash programming.

Save MAMCR, set to 0 (disabled) before IAP, restore after.
The IAP ROM uses 128 bytes of the caller's stack internally.
With command[5] and result[3] on the stack, the IAP's own stack
frame could overwrite them before reading all parameters.

Moving to static BSS ensures they're in a safe, fixed location.
If IAP works with sector 10 but not sector 1, the issue is
lpc21isp interference with sector 1. If sector 10 also fails,
the IAP calling convention is the problem.
@ImNoahDev ImNoahDev merged commit 740fac1 into master Mar 22, 2026
1 check passed
@ImNoahDev ImNoahDev deleted the IAP branch March 22, 2026 13:26
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant