#debugging #embedded #riscv #mcu
Вопрос:
Я работаю с микроконтроллером K210. и по некоторым причинам микроконтроллер выходит из строя со следующим журналом дампа ядра :
core 0, core dump: illegal instruction Cause 0x0000000000000002 reg[00](mpec ) = 0xffffffef6c6c6548, reg[01](ra ) = 0x6c65486f6c6c6548 reg[02](sp ) = 0x00000000801f8e50, reg[03](gp ) = 0x0000000000000000 reg[04](tp ) = 0x0000000000000000, reg[05](t0 ) = 0xffffffffffffffff reg[06](t1 ) = 0x000000008005ee3a, reg[07](t2 ) = 0x0000000080072a24 reg[08](s0/fp) = 0x6f6c6c65486f6c6c, reg[09](s1 ) = 0x65486f6c6c65486f reg[10](a0 ) = 0x0000000000000001, reg[11](a1 ) = 0x0000000000000002 reg[12](a2 ) = 0x00000000800e3f2e, reg[13](a3 ) = 0x00000000801f9138 reg[14](a4 ) = 0x00000000801f9138, reg[15](a5 ) = 0x0000000000000000 reg[16](a6 ) = 0x0000000000000000, reg[17](a7 ) = 0x0000000000000040 reg[18](s2 ) = 0x6c6c65486f6c6c65, reg[19](s3 ) = 0x486f6c6c65486f reg[20](s4 ) = 0x6c65486f6c6c6548, reg[21](s5 ) = 0x6f6c6c65486f6c6c reg[22](s6 ) = 0x0000000000000001, reg[23](s7 ) = 0x000000000000003a reg[24](s8 ) = 0x00000000800fb271, reg[25](s9 ) = 0x0000000000000004 reg[26](s10 ) = 0x0000000000000000, reg[27](s11 ) = 0x000000000000003e reg[28](t3 ) = 0x00000000800733ae, reg[29](t4 ) = 0x00000000801f8dc0 reg[30](t5 ) = 0x0000000000000010, reg[31](t6 ) = 0x0000000000000000 freg[00](ft0 ) = 0x7d22656e00000000, freg[01](ft1 ) = 0x6d641b0000000000 freg[02](ft2 ) = 0x73752f7400000000, freg[03](ft3 ) = 0x7574617400000000 freg[04](ft4 ) = 0x7365757100000000, freg[05](ft5 ) = 0x1a00030000000000 freg[06](ft6 ) = 0x2f74616800000000, freg[07](ft7 ) = 0x6174732f00000000 freg[08](fs0 ) = 0x6164707500000000, freg[09](fs1 ) = 0x0004005000000000 freg[10](fa0 ) = 0x6e616c6900000000, freg[11](fa1 ) = 0x672f637000000000 freg[12](fa2 ) = 0x6563697600000000, freg[13](fa3 ) = 0x722f676900000000 freg[14](fa4 ) = 0x2f65736e00000000, freg[15](fa5 ) = 0x3161373800000000 freg[16](fa6 ) = 0x30342d6200000000, freg[17](fa7 ) = 0x2d65613600000000 freg[18](fs2 ) = 0x3064333800000000, freg[19](fs3 ) = 0x02c9300200000000 freg[20](fs4 ) = 0x616c696700000000, freg[21](fs5 ) = 0x2f63707200000000 freg[22](fs6 ) = 0x6369766500000000, freg[23](fs7 ) = 0x2f67696600000000 freg[24](fs8 ) = 0x4874736500000000, freg[25](fs9 ) = 0x6c6c654800000000 freg[26](fs10) = 0x65486f6c00000000, freg[27](fs11) = 0x6f6c6c6500000000 freg[28](ft8 ) = 0x6c65486f00000000, freg[29](ft9 ) = 0x486f6c6c00000000 freg[30](ft10) = 0x6c6c654800000000, freg[31](ft11) = 0x65486f6c00000000 (93351720) SYSCALL: sys_exit called with 0x539 Мой вопрос в том, можно ли отследить, в какой строке проблема только с использованием этой информации о дампе ядра и извлеченного файла разборки riscv64-unknown-elf-objdump ?
Комментарии:
1. Эти свалки всегда довольно бесполезны. У вас есть микроконтроллер с трассировкой инструкций? Если это так, то просто установите точку останова в соответствующем аппаратном исключении и просмотрите трассировку, чтобы узнать, как вы там оказались. 10 минут отладки вместо 10 часов/дней.
2. да, в этом есть смысл. Я действительно могу использовать OpenOCD, чтобы отследить причину. Однако я просто хотел знать, есть ли возможность отследить адрес, по которому возникает эта проблема, просто посмотрев на дамп ядра?
3. Найдите, как называется счетчик программ в этой части, и там он у вас должен быть. Если только он не указывает на местоположение обработчика исключений, то есть — в этом случае дамп ядра не очень полезен. Кроме того, незаконные ловушки для инструкций обычно предполагают неконтролируемый код, поэтому счетчик программ может быть глубоко в ла-ла-ленде.
4. Что такое ан
mpec?5. может
mpecбыть, так оно и естьmepc?