Hi,
I'm using an MBC4300 dev board and my application is using CMSIS-RTOS (messaging etc). My system is up to date (see below):
I am having difficulty debugging, here is what happens.
1. I compile my project (it loads automatically). 2. I can run it and set break points. 3. I can also look at values and monitor RTOS timers in real time. 4. I can stop and re-start. 5. My heart beat LED is flashing 6. However if I stop, reset the debugger (button in uVision) and press start I cannot stop anymore!! 7. Pressing the stop button I get the U:INK-Cortex-M Error message "Could not stop Cortex-M device! Please check the JTAG cable" 8. Press OK to the error message and it jumps out of debug and will not go back in, with same error message. 9. After OKing to this message I also get another message: "Error: Target DLL has been cancelled. Debugger aborted!" 10. Pressing reset on target PCB allows me to re-program / get back into debugger but pressing stop gives same error as no.6 above.
The only way to get it going again is to:
1. press reset on target PCB 2. load blinky (CMSIS RTOS version) project 3. download and run blinky 4. re-load my project and download to target.
Now I can do a one off debug as above.
Please can you tell me what I'm doing wrong?
Thanks
Ian
IDE-Version: µVision V5.11.1.0
Tool Version Numbers: Toolchain: MDK-ARM Professional Version: 5.11.0.0 Toolchain Path: C:\Keil_v5\ARM\ARMCC\bin\ C Compiler: Armcc.Exe V5.04.0.49 Assembler: Armasm.Exe V5.04.0.49 Linker/Locator: ArmLink.Exe V5.04.0.49 Librarian: ArmAr.Exe V5.04.0.49 Hex Converter: FromElf.Exe V5.04.0.49 CPU DLL: SARMCM3.DLL V5.11.0.0 Dialog DLL: DCM.DLL V1.11.0.0 Target DLL: UL2CM3.DLL V1.152.17.0 Dialog DLL: TCM.DLL V1.14.1.0
One would suspect you have some objectionable code in your reset path.
SWD or JTAG? NRST/NRESET pin connected?
I'm using SW and reset after connect is selected, I think the hardware reset line is there on an MCB4300.
I single stepped the code from the first reset and all is OK. After a second reset it calls SystemInit() but does not return from SystemInit_ExtMemCtl()! Here is where it gets stuck:
/* Mode register: Burst Length: 4, Burst Type: Sequential, CAS Latency: 3 */ WR_MODE(((3 << 4) | 2) << 12);
Once my code has been executed calling this line will kill the debugger?
One thing that is odd is I don't have DMA selected for my UART in my RTE_Device.h but it is required in manage run-time environment dialog if you select CMSIS UART driver? When I did have it selected things went crazy.
Any ideas?
Depending on how you reset (wrt memory accesses ongoing), it's possible to get SDRAM into objectionable states. Seen situations with ATMEL AT91SAM9 parts where it breaks the EBI precluding access to NAND on the same bus. Figure out how to clear the controller and the devices attached to it, especially when they don't have their own NRESET connection.]
Generally code in SystemInit() tends to assume certain reset states, and is not particularly robust if initial conditions aren't as expected. ie Explicitly reset things, don't assume they come reset.
"Generally code in SystemInit() tends to assume certain reset states, and is not particularly robust if initial conditions aren't as expected. ie Explicitly reset things, don't assume they come reset."
This is also one thing people tends to forget when they think they can just jump to the reset vector instead of performing a full hardware reset. Lots of code is written based on assumptions that aren't well documented (or even documented at all). And broken assumptions leads to broken expectations and tears soon to follow.
Guys, thanks for your responses..
OK changing both these to 0 got me results....as I'm not using any external memory.
*---------------------------------------------------------------------------- Configure external memory controller options *----------------------------------------------------------------------------*/ #define USE_EXT_STAT_MEM_CS0 1 /* Use ext. static memory with CS0 */ #define USE_EXT_DYN_MEM_CS0 1 /* Use ext. dynamic memory with CS0 */
Human (me) error! Basically I a bit rusty (about 2 years since using LPCs) and "assumed" the setup files for the MBC4300 were correctly setup for the board and every thing will work together:) I think two things are happening here: 1. There is only SDRAM on the boards (but maybe the SRAM is setup for the 2 flash chips)? 2. I'm using UART3 which just happens to use some rather important Address/Data lines used by the memory.
This is a temporary target while the proper one is being designed/build and I didn't bother to check the pin mux!
Assume any example or boiler-plate code is there for "Demonstrational Purposes Only", and needs to be understood, and tailored to the specific use case, and board/pin/part configuration chosen by the user.
Very true....thanks again. Ian