- Silicon Labs Community
- Welcome and Announcements
- Silicon Labs Knowledge Base
- 8-bit MCU
- 32-bit MCU
- Bluetooth / Wi-Fi
- Other Products Category
- Optical/RH/Temp Sensor
- Other Products
- Hardware and Software Tools
- Simplicity Studio and Software
- General Discussions and Suggestions
- Chinese Forum
- Software Libraries
- Development Kits
- Reference Designs
- Third Party Tools
- White Papers
- Official Blog of Silicon Labs
- Chinese Blog
08-18-2017 04:10 PM
I compiled a program using Keil Microvision 5, and programmed the generated hex file onto a C8051F385 MCU using the Silabs Flash Programming Utility and the Silabs USB debug adapter. The program worked as expected in circuit (I have LEDs on the board to indicate the program status). Then I tried to use the Keil debugging tool to look at the code execution. The code seemed not to work in this mode and wouldn't reach my breakpoints at the very first instruction. After I was done, I tried reprogramming the board in the normal way, and now I see no response from the MCU in circuit.
I'm trying to understand what Keil could have changed about the MCU and how to reverse it if possible. I'm new to MCU programming and am confused about what changes outside the programming hex file are possible and could cause my MCU to become unresponsive. I would greatly appreciate any help in this matter or pointers to any resources relevant to my situation.
Thank you for your attention.
08-18-2017 07:13 PM
The program worked as expected in circuit
Then I tried to use the Keil debugging tool to look at the code execution. The code seemed not to work in this mode
After I was done, I tried reprogramming the board in the normal way, and now I see no response from the MCU in circuit.
at some time between 1) and 2) something in your source changed
08-22-2017 04:53 PM
I've tried the "Erase Code Space" in my Flash Utility, and I've tried various archived programming files that have worked before, but with the same result. Are there any registers that could affect the functioning of the MCU outside of Code Space?
My debugger shows the disassembly as entirely 0xFF instructions until the program begins at address 0x1400. However, the MCU only gets through about address 0x0BB0 (this number seems to vary) before resetting to the beginning of program memory.
08-23-2017 04:00 AM
If you can view the code contents and disassemble you've certainly not locked the MCU.
But if the code starts with 5000 dummy instructions (0xFF, mov r7,r7) then the watchdog bites before you reach the actual program.
08-23-2017 09:01 AM
My debugger shows the disassembly as entirely 0xFF instructions until the program begins at address 0x1400
there must be something at 0x00-0x03
check again, if not we have a starting point
08-23-2017 01:03 PM
I scrolled through all 0x13FF lines and found entirely FF instructions. Furthermore, I've stepped through the code and have seen it go straight from an FF instruction back to instruction 0. Is there a way to tell the compiler not to insert so many of these instructions before the actual code?
08-23-2017 01:29 PM
One more piece of information that I found odd is that when I am in debug mode, and the "stop code execution" button is pressed, the instructions after 0x1400 appear as normal:
C:0x1400 026888 LJMP STARTUP1(C:6888) ,for example.
But when I press the "run" button and scroll around, all the instructions in the disassembly view change to the instruction my cursor was on when the run button was pressed. It goes back to normal again when I hit "stop". I have tried extracting sections of code with the silabs tool, and can see that the assembly code looks normal from there (albeit with 5000 0xFFs in front), so maybe this is just a quirk of the Keil debugger.
08-23-2017 01:44 PM - edited 08-23-2017 01:45 PM
as far as I can see, you suffer from the - not uncommon - mistake that relocating the vectors goes into the chip and changes it.
whatever you do the chip starts at 0x00
I guess you do not have (some flavor of) startup,a51 included in your build
08-23-2017 02:34 PM
I do in fact! I am running USB_BL_APP_F38x_64k_STARTUP.A51, I just didn't know enough to change it. So I found START_APPLICATION EQU 01400h and changed it to 00400h. Now the program will at least make it to some startup instructions, which I appreciate. However, I am now in very unfamiliar territory, and the program still doesn't run to main(). I suppose I'll have to figure out where else to make this change. The comment for the line reads:
; Entry point of the User Application Firmware
; Change should be mirrored in this project's Compiler & Linker command lines
; Should also be mirrored in BL FW's STARTUP.A51 and USB_BL_Defs.h
; And also in BL SW's FirmwareInterface.h
I also have:
; Compiler command line: DB OE INTVECTOR(0x1400) INTERVAL(3)
; Linker command line: RS(256) PL(68) PW(78) CODE(0x1400-0xF9FD)
but I'm not sure where to find these command lines/what a command line is in this context.
At least I feel like I'm getting somewhere now
08-23-2017 06:57 PM
you are mucking around in things you do not understand. Start by knowing the '51
08-24-2017 03:19 AM
Your code is set up to coexist with a BootLoader (BL) from 0x0000-0x13FF, but in reality there is none in your MCU. So either find out which bootloader it expects and how to insert it or do away with this principle.
09-01-2017 05:15 PM
Thanks for the pointers, Erik and Maarten! I haven't fully figured this out yet because I've had to work on some other things this past week, but now I at least have some ideas and new areas to learn about.