adamgreen / mri Goto Github PK

I had a silly bug in my platform code:

NVIC_SetPriority(USART0_IRQn, 0);
mriCortexMInit(NULL, 0, LAST_IRQn);

The two lines being in wrong order, USART interrupt ends up being below DebugMon interrupt.
This in turn causes very weird behavior as soon as step command is used, because the monitor ends up trying to single-step itself.
Funnily enough it sometimes even worked to some extent.

I wonder if it would be worth it to add a check to verify that the currently executing interrupt is at correct priority before trying to step?
Getting the interrupt priorities wrong seems like an easy mistake to make, and the consequences are very difficult to figure out.
Though I'm not sure what to do if the check fails, best would be to report error to gdb somehow so developer knows to fix their platform code.

I have had a request to change MRI away from the LGPL license to something more permissive. I would like to switch it to Apache.

@JaredCJR @jserv Do you have any issue with the license on your contributions being switched to use an Apache license?

I saw that there are few places change the behavior by checking MRI_THREAD_MRI:
https://github.com/adamgreen/mri/search?q=MRI_THREAD_MRI
@adamgreen in which case we can get the benefit to this flag?

Hello Adam - apologies, this is probably not the optimal way to reach out and ask questions. But presumably the same principle would apply to an NXP43XX series or indeed one of the mbed enabled Freescale K64F devices?

@icecream95 reported this issue in his PR #32.

I was able to reproduce the hang in MRI by attempting to single step at the source level (using step and not stepi) over the following instruction:

    *(volatile uint32_t*)0xFFFFFFFF;

There is a bug in MRI where handling ranged single stepping is taking precedence over exception handling. I will start working on a fix for it soon.

Hello Adam,

Could you please help me in the following strange situation. I'm trying to use some part of your code because I would like to play the DWT function of cortex m4.

I'm initializing DWT and setup one watchpoint in the following way:

     enableDWTandITM();
      initDWT();
      clearMonitorPending();
      enableDebugMonitorAtPriority0();
      enableDWTWatchpoint(0x2001E893, 4, DWT_FUNCTION_READ);

I don't change the priority of the other interrupts to 1 or higher and I've removed the inline modifiers.

This memory address periodically accessed by OSTaskIdleHook function in an uc/OS-II kernel.

The __mriDebugException function is very simple:

void __mriDebugException(void) {
void *sp;
asm("mov %0,r13" : "=r" (sp));
printf("mri sp: %x\n", sp);
}

After some debug exception a hard fault occurs.

The value of sp in __mriDebugException does not change so I think it's not a stack overflow.

Some info from the hard fault handler:

LR [R14] = 804e14b subroutine call return address
PC [R15] = 80323ec program counter
PSR = 200
BFAR = e000ed38
CFSR = 20000
HFSR = 40000000
DFSR = 4
AFSR = 0
SCB_SHCSR = 0

The values of LR and PC are same like in debug handler so PC points after the instruction that read that address specified at watchpoint.

CFSR bit 17 is one, referring to the documentation it is INVSTATE: Invalid state usage fault. When this bit is set to 1, the PC value stacked for the exception return points to the instruction that attempted the illegal use of the EPSR. This bit is not set to 1 if an undefined instruction uses the EPSR.

0: No invalid state usage fault
1: The processor has attempted to execute an instruction that makes illegal use of the EPSR.

Do you have any idea what's happening?

It is an stm32f405 mcu.

README(https://github.com/adamgreen/mri/blob/master/README.md?plain=1#L14) mention that:

stdout/stderr/stdin are redirected to/from the GDB console

@adamgreen could you tell me the detailed step to setup for both(gdb and device) side? Thanks.

I think most of people would like to use mri without gcc4mbed,so I write some guides here hoping that could be add to the README for people who want to using mri could pick it up more quickly!

• Makefile variable relative to mri
  • add the $MRI_FLAGS to the CFLAGS
  • add $MRI_libraries to the object files lists to link with the final executable file

# MRI paths  
MRI_ROOT_DIR:=/path/to/the/mri
MRI_LIB_DIR:=$(MRI_ROOT_DIR)/lib/armv7-m
MRI_libraries:=$(MRI_LIB_DIR)/libmri_stm32f429-disco.a

# MRI variable
MRI_ENABLE?=1
DEVICE_MRI_ENABLE:=$(MRI_ENABLE)
MRI_BREAK_ON_INIT?=0
MRI_UART?=MRI_UART_2 
MRI_INIT_PARAMETERS?=$(MRI_UART)

MRI_FLAGS:=\
        -DMRI_ENABLE=$(DEVICE_MRI_ENABLE) \
        -DMRI_INIT_PARAMETERS='"$(MRI_INIT_PARAMETERS)"' \
        -DMRI_BREAK_ON_INIT=$(MRI_BREAK_ON_INIT)

• Initialization C code
  • Place the code in the proper place.
  • In default,mri will configure the NVIC,USART,MPU and other debug monitor relative registers(including DWT and FPB)
    • debug monitor interrupt priority must higher than all external interrupts.
    • internal exception handlers will be direct to mriFaultHandler or __mriExceptionHandler.

    if (MRI_ENABLE)                                                                            
    {
        __mriInit(MRI_INIT_PARAMETERS);
        if (MRI_BREAK_ON_INIT)
            __debugbreak();
    }

Thanks!

I am getting the following error using LPC1768

Ignoring packet error, continuing...
warning: unrecognized item "timeout" in "qSupported" response

firmware=21164&configuration=4

which arm-none-eabi-gdb gives me the binary built from gcc4mbed
A Serial PC HelloWorld program prints successfully with screen

screen /dev/tty.usbmodem1412 230400

Although sending $#00 does not return anything.

arm-none-eabi-gdb FileTest.elf --baud 230400 -ex "set target-charset ASCII" -ex "set print pretty on" -ex "set remotelogfile mri.log" -ex "target remote /dev/tty.usbmodem1412"

GNU gdb (GNU Tools for ARM Embedded Processors) 7.10.1.20151217-cvs
Copyright (C) 2015 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "--host=x86_64-apple-darwin --target=arm-none-eabi".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
http://www.gnu.org/software/gdb/bugs/.
Find the GDB manual and other documentation resources online at:
http://www.gnu.org/software/gdb/documentation/.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from FileTest.elf...done.
Remote debugging using /dev/tty.usbmodem1412
Ignoring packet error, continuing...
warning: unrecognized item "timeout" in "qSupported" response
Ignoring packet error, continuing...
Ignoring packet error, continuing...

--and from time-to-time I get this: at the end
Bogus trace status reply from target: timeout

I would appreciate any help, I'm looking forward to using this debugger

The error messages are as follows:

Building lib/host/libCppUTest.a
Building CPPUTEST_tests
Runnning CPPUTEST_tests
make: CPPUTEST_tests: Command not found
makefile:199: recipe for target 'RUN_CPPUTEST_TESTS' failed
make: *** [RUN_CPPUTEST_TESTS] Error 127

Thanks

Hi !

I think I found a bug in MRI. I'm trying to use the SPI port on smoothieboard ( also UART1 ) to do MRI debugging. Not sure yet it's a bug though. Basically when using MRI_UART_MBED_P13_P14, the RX pin never receives anything from the host.

In here : https://github.com/adamgreen/mri/blob/master/mri/platforms/devices/lpc176x/lpc176x_uart.c
When using the MRI_UART_MBED_P13_P14 option, that means it's using the second element in the config array, that is :

{
    &(LPC_SC->PCLKSEL0),
    &(LPC_PINCON->PINSEL0),
    &(LPC_PINCON->PINSEL1),
    (LPC_UART_TypeDef*)LPC_UART1,
    1 << 4,
    3 << 8,
    3 << 30,
    3 << 0,
    0x55555555
},

Now it is supposed to set pin 15 to be TXD1 ( I don't get the 3 but it's everywhere so I trust yout here ) and pin 16 to be RX1.
You are using 3<<8 and 3<<30 respectively. But according to the datasheet I think it should be 3<<30 and 3<<0.
The fact that 3<<30 is TX and TX works but not RX, and here it's the only one that is in agreement makes me suspect I'm correct.

Now the weird thing is, I was previously trying to use UART1 as my main UART for smoothie coms, and UART0 for MRI, and when I did that, I had the same problem ( I think, not sure ), so maybe something weird else is going on here.

Cheers !

I used the existing armv7-m code on armv8-m. So far, I found that there is no difference in use except that the register order of DWT_COMP is different, so we can use macros to distinguish whether to use armv7-m or armv8-m, and then use armv7-m code? Or rewrite a arch of support for armv8-m?