Next revision | Previous revision |
projects:3dprinting:flashforge_creator_3_pro_fan_fix:patching [2024/10/24 16:32] – created admin | projects:3dprinting:flashforge_creator_3_pro_fan_fix:patching [2024/10/24 22:03] (current) – admin |
---|
clz r0, r0 @ (0x1318da b0 fa 80 f0) | clz r0, r0 @ (0x1318da b0 fa 80 f0) |
b #0x1318ec @ (0x1318de 05 e0) | b #0x1318ec @ (0x1318de 05 e0) |
@ ... continue at lsrs r0, r0, #0x5 and then b #0x1316d6 | |
/** | @ - or - |
LAB_001318e0 (prepare for M26 command) | @ b.w #0x1318ec @ (0x1318de 00 F0 05 B8) |
mov r0,r5 @ arg 1 (0x1318e0 28 46) | @ @ ... continue at lsrs r0, r0, #0x5 and then b #0x1316d6 |
ldr r2, [sp, #0x20] @ arg 3 (0x1318e2 08 99) | |
bl #0x129c44 @ handle m601 (0x1318e4 f8 f7 ae f9) | @ |
clz r0,r0 @ (0x1318e8 b0 fa 80 f0) | @ LAB_001318e0 (prepare for M26 command) |
lsrs r0,r0,#0x5 @ (0x1318ec 40 09) | @ mov r0,r5 @ arg 1 (0x1318e0 28 46) |
b #0x1316d6 @ (001318ee f2 e6) | @ ldr r2, [sp, #0x20] @ arg 3 (0x1318e2 08 99) |
*/ | @ bl #0x129c44 @ handle m601 (0x1318e4 f8 f7 ae f9) |
| @ clz r0,r0 @ (0x1318e8 b0 fa 80 f0) |
| @ lsrs r0,r0,#0x5 @ (0x1318ec 40 09) |
| @ b #0x1316d6 @ (001318ee f2 e6) |
| @ |
</code> | </code> |
| |
But during testing, the printer crashed at receiving command M26 with an "illegal instruction" error. A backtrace in gdb showed where the problem was: The branch instruction at address 0x1318de, b #0x1318e8, occupied not 2 but 4 bytes and thus overwriting partly the function for M26. | But during testing, the printer crashed at receiving command M26 with an "illegal instruction" error. A backtrace in gdb showed quickly where the problem was: The branch instruction at address 0x1318de should have been a "b #0x1318e8" (05 e0), but the assembler converted the branch instruction into "b.w #0x1318ec" (00 F0 05 B8) and thus overwriting partly the function for M26. |
| |
Why [[https://sourceware.org/binutils/docs/as.html|GNU as]] encoded the branch instruction into a 32 bit instruction I do not yet know. The easiest solution was to accept that the instruction may occupy 32 bit, and branch from one instruction earlier. So instead of "0x1318da clz r0,r0" followed by "0x1318de b #0x1318ec" it would just do "0x1318da b #0x1318e8": | Why [[https://sourceware.org/binutils/docs/as.html|GNU as]] encoded the branch instruction into a 32 bit instruction I do not yet know. The easiest solution was to accept that the instruction may occupy 32 bit, and branch from one instruction earlier. So instead of "0x1318da clz r0,r0" followed by "0x1318de b #0x1318ec" it would just do "0x1318da b #0x1318e8": |