| Details | Message |
|---|
Read-Only Author David Sudolcan Posted 21-Jul-2009 16:39 GMT Toolset ARM |  *** error 57: illegal address (0x8000000) David Sudolcan I get the below error message when I start the ULINK debugger with my KEIL MCBSTM32 eval board: Cannot access Memory *** error 57: illegal address (0x8000000)
I've searched KEIL's website for error 57, but couldn't find anything. I've searched uVsion help, but couldn't find anything. Can someone point me to where these types of errors are documented? The debugger is actually stopped at address 0x80001A4, and these are the instructions before and at that line: 0x080001A0 F002BBF6 B.W 0x080002990 0x080001A4 4804 LDR r0,[PC,#32] ; @0x080001C8
and this is what's at 0x080001C8:
0x080001C8 00ED LSLS r5,r5,#3
and this is what's at 0x08002990:
0x08002990 4770 BX lr
Address 0x8000000 is the start of flash ROM for the uC on this eval board (an STM32F103RBT6). I'm using the default KEIL assembly startup code (STM32F103x.s) and the default project options for where ROM and RAM is (IROM1 at 0x8000000 with size = 0x20000, and IRAM1 at 0x20000000 with size = 0x5000). If I start the debugger then stop it, I get this error message: ULINK - Cortex-M Error Could not stop Cortex-M device! Please check the JTAG cable
I found some knowledgebase articles that suggested slowing down the JTAG clock, using internal or external 3.3V inside the ULINK, and/or making sure that a hardware reset was used with the ULINK; so I tried those suggestions. Unfortunately, they didn't change my symptoms. I've been trying to find somwhere where I could insert a breakpoint to try to step through the startup code, but uVision won't let me put a breakpoint anywhere in the startup assembly code (and yes, I do have the "Debug Information" checkbox checked in the project options). I've unchecked the debugger "Reset and Run" and "Run to main()" options, but when I start the debugger and try to single step, I can only step a few times and then the code appears to start and never stop. If I hit the "halt" button, I get the same error message about not being able to stop the uC. The debugger always starts at address 0x080001A4 with the error message about not being able to access memory. Can anyone suggest something else to do that might fix these problems? Thanks, Dave. |
|
Read-Only Author David Sudolcan Posted 21-Jul-2009 17:11 GMT Toolset ARM |  RE: *** error 57: illegal address (0x8000000) David Sudolcan Well... I had tried a new way to organize source code for this project, and on a whim I decided to go back to my old way of organizing it (all source code for the project in one directory). That made the error 57 error go away. No idea why that is! Also, now I get the assembly source code in the disassembly window (which I didn't get before), and I can see that the line of code where the debugger stops (0x080001A4) is where the assembly code is trying to jump to the library startup code (I think): 117: LDR R0, =__main 0x080001A4 LDR r0,[PC#32] ; @0x080001C8
If I "step into" at that point, the debugger stops at: __main: 0x080000EC BL.W __scatterload_rt2_thumb_only (0x080000F4)
I started single-stepping through this code, and it seems to run okay (the debugger doesn't crash); but if I try to run to [my] main, the debugger never makes it there. If I then try to halt the debugger, I get that same error message about not being able to stop the debugger. Should I expect the KEIL IDE to work right with projects where the source code is not in a single directory? Also, other than including the cortexm3_macros.s and cortexm3.h files in my project, do I need to do anything else in order to be able to use the macros in these files? Does anyone know if there's a problem with the default startup code for the STM32F10x parts? Thanks, Dave. |
|
Read-Only Author David Sudolcan Posted 23-Jul-2009 05:06 GMT Toolset ARM |  RE: *** error 57: illegal address (0x8000000) David Sudolcan Well... reorganizing the project code helped (when I first did it), but error 57 comes back somewhat randomly whenever I build new code. I'm stumped... sometimes I can use the hardware debugger, but usually I can't (because of error 57, which won't let me set breakpoints when it's active). Anyone have any suggestions...? Sigh... Dave. |
|
Read-Only Author Alex Ruiz Posted 3-Aug-2009 14:18 GMT Toolset ARM |  RE: *** error 57: illegal address (0x8000000) Alex Ruiz Not sure if it's the problem with your project, but I did face this message in a near past. Here's what I did: Under Options for Target->Debug->Ulink Cortex Debugger->Settings->Debug you may try disabling Download to Flash under Download Options ( far right end ). You may download to flash manually before entering debugging. (if firmware has changed). BR, |
|
Read-Only Author Milorad Cvjetkovic Posted 3-Aug-2009 08:07 GMT Toolset ARM |  RE: *** error 57: illegal address (0x8000000) Milorad Cvjetkovic Hi, can you try Blinky example provided with MDK for that board and then build on it? |
|
Read-Only Author Thorsten de Buhr Posted 3-Aug-2009 09:03 GMT Toolset ARM |  RE: *** error 57: illegal address (0x8000000) Thorsten de Buhr btw... did you try a new project using cmsis? There are less files included/used than in the ST Lib projects - perhaps easier. Just a startup (s) and a init (c), a SystemInit() in main() does the nessessary work. BR, /th. |
|
Read-Only Author David Sudolcan Posted 3-Aug-2009 17:01 GMT Toolset ARM |  RE: *** error 57: illegal address (0x8000000) David Sudolcan Thanks for all the suggestions. I did try the Blinky project, and it worked. I un-checked "Download to Flash", downloaded the code manually, and now the debugger seems to be working again. I'll keep my fingers crossed and hope that the debugger keeps working if I do things this way. It still bothers me though that I can't find a list on KEIL's website that describes this error (or any others). I so miss the old hard copy manuals you used to get with the tools. I hate these online ones where if you don't know the right keyword, it can be virtually impossible to find what you're looking for! Surely a search term like "error list" (or at least one of several variations of that) should produce a link to a list of errors (including error 57). |
|
Read-Only Author Andy Neil Posted 3-Aug-2009 17:20 GMT Toolset None |  I so miss the old hard copy manuals Andy Neil I don't miss hardcopy - but I do miss the PDFs. "I hate these online ones where if you don't know the right keyword, it can be virtually impossible to find what you're looking for!" Absolutely See: http://www.keil.com/forum/docs/thread15201.asp And: http://www.keil.com/forum/docs/thread15011.asp |
|
Read-Only Author Andy Neil Posted 3-Aug-2009 17:21 GMT Toolset None |  RE: I so miss the old hard copy manuals Andy Neil BTW the *** error 57: is probably a Debugger error - not a compiler error... |
|
Read-Only Author David Sudolcan Posted 3-Aug-2009 17:42 GMT Toolset None |  RE: I so miss the old hard copy manuals David Sudolcan Since my project compiles and links with zero errors or warnings, I wouldn't think that the error I've been talking about would be a compiler error. I've looked in the ULINK, uVision, and the RealView utilities online manuals, and can't find error 57 in any of them. I haven't been able to find a manual for the debugger. Can you tell me where I can find the list of errors that includes this error 57? |
|
Read-Only Author Andy Neil Posted 3-Aug-2009 21:36 GMT Toolset None |  I haven't been able to find a manual for the debugger. Andy Neil The debugger is an integral part of uVision - so it'd be in the uVision manual if it's anywhere. But, AFAIR, there has never been such a thing. :-( |
|
Read-Only Author David Sudolcan Posted 3-Aug-2009 21:55 GMT Toolset None |  RE: I haven't been able to find a manual for the debugger. David Sudolcan Thanks Andy. Since my support agreement ended some time ago, I guess I have no valid/official method to complain, or to request support about this. My guess is that errors like these are documented somewhere in the public domain. I sure wish I knew where! :-<
|
|
Read-Only Author John Linq Posted 4-Aug-2009 04:45 GMT Toolset None |  RE: I haven't been able to find a manual for the debugger. John Linq ARM: MEMORY MISMATCH ERRORS DURING LOAD http://www.keil.com/support/docs/2925.htm ANSWER This can be caused by the microcontroller hardware not being reset properly. Check the Use Reset at Startup check box in the ARM Target Driver Setup Dialog (Options for Target -> Debug -> Settings). Checking this tells the debugger to send a hardware reset over the JTAG link before loading. |
|
Read-Only Author David Sudolcan Posted 4-Aug-2009 15:04 GMT Toolset ARM |  *** error 57: illegal address (0x8000000) David Sudolcan Thanks John. Unfortunately, I've tried this several different ways (I think every possible via the different dialog boxes), but it hasn't solved the problem. In case you haven't seen the earlier threads, I'm having this problem on both a KEIL MCBSTM32 eval board and an ST STM3210E eval board. I'm assuming that both of these eval board vendors know how to design reset circuits for them that are compatible with the KEIL debugger. |
|
Read-Only Author John Linq Posted 5-Aug-2009 02:18 GMT Toolset ARM |  RE: *** error 57: illegal address (0x8000000) John Linq Hi David, You are right. I thought that I had read this thread before, so I didn't scroll up, and then lost a lot of information in the earlier posts. I have a question, who creates/builds the problematic project? Is that some example you downloaded from Internet? |
|
Read-Only Author John Linq Posted 5-Aug-2009 02:25 GMT Toolset ARM |  RE: *** error 57: illegal address (0x8000000) John Linq If it is a project not created/built by yourself, then I will suggest that: 1.Extract all the source code out. 2.Create a totally new project, include all the source code in. 3.Configure the new project as your need. |
|
Read-Only Author David Sudolcan Posted 5-Aug-2009 04:59 GMT Toolset ARM |  RE: *** error 57: illegal address (0x8000000) David Sudolcan John, The project is of my own creation. I did start it from scratch; something I've done for many, many years using KEIL tools on 805x, C16x, and ARM projects. I did restart it, from scratch again, using a different STM32F eval board from a different vendor. The fact that I couldn't reliably (if at all) start the debugger until I followed a suggestion from someone else to load the code into the flash ROM manually (and disable starting the debugger from doing that) is what makes me think it's not my code/project that's the problem. My code runs fine on both eval boards, and I can use the debugger with ease on both eval boards, as long as I prevent starting the debugger from trying to load the code into the board. Well, at least that's how it's working now. So... the immediate problem has been solved (I can use the debugger now). However, the underlying cause is still there (starting the debugger and letting it load code into my eval boards prevents the debugger from being able to set a breakpoint or execute a single line of code). What's worse is I still haven't been able to find this error documented anywhere; or have anyone tell me what it really means and what causes it. |
|
Read-Only Author John Linq Posted 5-Aug-2009 06:25 GMT Toolset ARM |  RE: *** error 57: illegal address (0x8000000) John Linq I don't know much about this, but I am really curious about such a problem. I have an assumption. (Sorry for my limited technical ability and limited English ability.) [ I did try the Blinky project, and it worked. ] Maybe, when your specific application is running, the MCU enters a specific status, so that the MCU can not be halt/reset properly. If this is the case, then, after you fully erase the program on the MCU, the problem should disappear for once. |
|
Read-Only Author David Sudolcan Posted 5-Aug-2009 15:22 GMT Toolset ARM |  RE: *** error 57: illegal address (0x8000000) David Sudolcan John, Since I can't even execute the 1st line of code when I have this error, I don't see how it could be my app's fault that the debugger won't run. But, I went ahead and tried your suggestion anyway after re-enabling "Download to Flash" under "Download Options" in the "Cortex-M Target Driver Setup". As soon as I did that, my error 57 problem re-appeared. I then manually erased the flash ROM and tried to start the debugger again, but error 57 came right back. There are over 70 source files in my project. I'll try putting them into the blinky project and see if that does anything. Dave. |
|
Read-Only Author Milorad Cvjetkovic Posted 5-Aug-2009 07:34 GMT Toolset ARM |  RE: *** error 57: illegal address (0x8000000) Milorad Cvjetkovic My suggestions are: - use Blinky as base and rename it, add your files and try it - compare all the settings in Bliny with settings in your project - make a while (1) loop at the beginning of main function to check if your code is producing problems You should be able to find out what the problem was by using last 2 suggestions, and by using first one you should be able to see if a setting in a project is a problem. |
|
Read-Only Author David Sudolcan Posted 5-Aug-2009 15:50 GMT Toolset ARM |  RE: *** error 57: illegal address (0x8000000) David Sudolcan I copied the Blinky OPT & UV2 files to a temp directory, stripped out all the source files, put all mine in, did a build all and tried to start the debugger... same problem. I copied the startup ASM code from the Blinky project to my project, rebuilt it, etc., but it made no difference. So, I tried the MCBSTM32's Blinky project, and now it has the same problem too. It worked the last time I tried it. Argh! Quite frustrating. |
|
Read-Only Author David Sudolcan Posted 5-Aug-2009 16:03 GMT Toolset ARM |  RE: *** error 57: illegal address (0x8000000) David Sudolcan OOPS... I just got my MCBSTM32 board back from a coworker and didn't notice that he'd moved the BOOT0 jumper (he's working on a bootstrap loader). I had been using the STM3210E eval board till this morning. I put the BOOT0 jumper back to where it was and now at least both my project and the Blinky project run once more. However, they both exhibit the error 57 problem when I let the debugger download code to flash, and the debugger works with both of them when I disable the debugger from downloading code to flash. |
|