Eclipse MCU J-Link Debugger Cra sh на ldrb r3, [r7, # 8]. Адреса действительны - [Правка - Проблема с оборудованием] - PullRequest
Новая
       81

Eclipse MCU J-Link Debugger Cra sh на ldrb r3, [r7, # 8]. Адреса действительны - [Правка - Проблема с оборудованием]

0 голосов
/ 07 апреля 2020

[Редактировать] Это оказалось аппаратной проблемой. Отдельный поток включал усилитель мощности радио, и мой предел тока источника питания сработал. Другой поток всегда активировался именно тогда, когда выполнялась эта инструкция]

Я борюсь с этим cra sh при отладке моего проекта.

Процессор SAM4LS8 (Cortex-M4). Я использую Eclipse MCU 2018/09 Отладка с помощью отладчика SEGGER J-Link. Использование FreeRTOS 8.2.1 и Atemel ASF.

У меня есть особая инструкция, которая вызывает сбой отладчика, когда я перехожу через него. Я уверен, что инструкция и адреса верны, поэтому я не думаю, что проблема заключается в самой инструкции.

Если эта проблема вам знакома, я был бы признателен за ваш вклад. Это меня убивает. 

ldrb r3,[r7,#8]

r7 Имеет значение 20004490 (то же самое, что и в lr). Доступная переменная является автоматической c переменной, и отладчик успешно извлекает значение этой переменной из адреса 0x20004498, как и ожидалось. Когда я пытаюсь выполнить пошаговое выполнение инструкции, на консоли отладчика появляется следующее. Похоже, что один шаг не останавливается правильно. (Я включил вывод, в котором отладчик успешно считывает значение переменной до шага). 

Read 1 bytes @ address 0x20004498 (Data = 0x00)
Setting breakpoint @ address 0x0000C71C, Size = 2, BPHandle = 0x000A
Setting breakpoint @ address 0x0000C754, Size = 2, BPHandle = 0x000B
Setting breakpoint @ address 0x0000CEDC, Size = 2, BPHandle = 0x000C
Performing single step...
ERROR: CPU is not halted
ERROR: Can not read register 15 (R15) while CPU is running
...Breakpoint reached @ address 0x00000000
Reading all registers
ERROR: Can not read register 0 (R0) while CPU is running
ERROR: Can not read register 1 (R1) while CPU is running

После того, как стек сбойных регистров читает и сбойная память читает около 0xDEADBEEF, отладчик восстанавливается со следующим выводом : 

Reading 64 bytes @ address 0xDEADBEC0
WARNING: Failed to read memory @ address 0xDEADBEC0
WARNING: Failed to read memory @ address 0xDEADBEEC
Received monitor command: clrbp
Received monitor command: reset
Resetting target
Received monitor command: halt
Halting target CPU...
...Target halted (PC = 0x000104E0)
Read 2 bytes @ address 0x00014F08 (Data = 0xB508)
Received monitor command: regs

Код c только что выполнил xQueueReceive (..) и успешно возвратился (cra sh находится в первой инструкции коммутатора (evt.event_type), и значение evt.event_type равно нулю (send_data). 

        if(pdFAIL == xQueueReceive(event_queue, &evt, BLOCK_TIMEOUT)){
            assert(!event_queue);
            evt.event_type = tx_done;
        }

        switch(evt.event_type){      << Crash happens here - loading evt.event_type to r3
        case sending_data:

Вот соответствующий ассемблер с отмеченной точкой cra sh: 

0000c702:   bl      0x864 <xQueueGenericReceive>
0000c706:   mov     r3, r0
0000c708:   cmp     r3, #0
0000c70a:   bne.n   0xc724 <send_frame+160>
341                 assert(!event_queue);
0000c70c:   ldr     r3, [pc, #168]  ; (0xc7b8 <send_frame+308>)
0000c70e:   ldr     r3, [r3, #0]
0000c710:   cmp     r3, #0
0000c712:   beq.n   0xc720 <send_frame+156>
0000c714:   ldr     r2, [pc, #176]  ; (0xc7c8 <send_frame+324>)
0000c716:   movw    r1, #341        ; 0x155
0000c71a:   ldr     r0, [pc, #168]  ; (0xc7c4 <send_frame+320>)
0000c71c:   bl      0x22d4 <__assert>
342                 evt.event_type = tx_done;
0000c720:   movs    r3, #3
0000c722:   strb    r3, [r7, #8]
345             switch(evt.event_type){
0000c724:   ldrb    r3, [r7, #8]                << Executing this instruction causes the crash

1 Ответ

0 голосов
/ 09 апреля 2020

Я обычно знаю, что отчаялся, когда начал обвинять аппаратные средства, но на этот раз это было (вроде) случай. Отдельный поток включал усилитель мощности радио, и мой предел тока источника питания сработал. Другой поток всегда активировался именно тогда, когда выполнялась эта инструкция, поэтому сбивал всю доску.

...