Reading through the information on the XK-1A Hardware Manual it states that I can write software to the flash memory so I don't have to program from my computer each time I power it on. However I can't figure out how to do this. How can I write programs to the flash memory on my XK-1A?
This is much easier than I thought and is not included in the instructions because it is very easy.
When programming using the xTIMEcomposer simply go to Run -> Flash Configurations then setup a new flash configuration for the current project and flash. It's that easy and you now have your program written in flash.
I used command prompt to program flash like this:
# check connection of XTAG and target board
xflash -l
# program flash
xflash project_bin.xb(or xe)
But first of all, you shoud have an xn file at the same folder of xb file, this xn file should confirgure all flash ic parameters of your project.
You can also use command line to creat a flash image for mass production either which is not your question anyway.
Related
I'm a newly graduated electronics engineer and one of my first tasks in my new job is to import a code to Mbed compiler.
I'm trying to run the Mbed Blinky example on my custom hardware with LPC1769 chip. I've exported the Blinky app to GNU Eclipse from the Online MBED compiler and imported it to the IDE.
The Mbed blinky code runs fine when I set the appropriate led pin(changing LED1 in the PinNames.h from 1.10 to 2.13 for my hardware) and flash it directly. So MBed and my custom HW isn't problematic. However, my firm has a custom bootloader and it's required to use it with any application. The custom bootloader requires that I start the program beginning from 0x4000.
For this my firm was previously adding this line to their code, flashing the bootloader and uploading the IDE's output .bin file to the board with a custom FW loading program.
SCB->VTOR = (0x4000) & 0x1FFFFF80;
When I try to follow the same steps, compiler builds without any complaints, but I see no blinks when I upload the program to my bootloader.
I'm suspecting I have to make some changes to the built-in CMSIS library, and/or the startup_LPC17XX.o and system_LPC17xx.o files come with the MBED export, but I'm confused. Any help would be much appreciated.
Also, I'm using the automatically built make file, in case there's any wonders.
Most importantly, you need to adjust the code location in the linker script, for example:
MEMORY {
FLASH : ORIGIN = 0x4000, LENGTH = 0x7C000
}
Check the startup code and linker script for any further absolute addresses in flash memory.
Adjusting the VTOR is required for interrupts, if the bootloader doesn't already do that. The & operation looks weird; it should be sufficient to simply write 0x4000, or, even better, something like:
SCB->VTOR = (uint32_t) &_IsrVector;
Assuming you have defined _IsrVector in your linker script or startup code to refer to the very first byte in the vector table, i.e. the definition of the initial stack pointer. This way you don't have to adjust the code if the memory layout is changed in the linker script, and you avoid magic numbers.
We're using Greenhills Multi IDE and Greenhills Debug Probe to program and debug our target system (a Coldfire based, bare metal system). Currently I flash the target using the IDE debugger GUI, but I would prefer to use a command line interface to do it.
The documentation is fairly sketchy, and only gives a very simple example. As far as I can tell I should be able to use grun with gflash to do this, but I'm having a hard time figuring out which GUI fields map to which grun options. Anyone with any experience of this?
Basically I need to be able to specify (see image above):
Flash device (this one I've got figured out I think)
Base address
Image file (we use raw images)
Offset in flash
Alternate RAM base
Alternate flash utility
Possibly also alternate MBS script
Any tips, tricks, or pointers to better documentation than the standard GHS one? Would be much appreciated!
Is below screenshot from debugger command reference is of any help? You can use it to download your source on HW. I will be able to share more details is this helps. Or you can share your solution if you had already found it.
I used mpadmin for this purpose.
mpadmin -update <IP-addr_of_your-probe | -usb> firmware.frm
Is there a utility that will show me a program's current memory contents? Like a hex dump of the entire memory being used by the program? Thanks.
My utility, Bit Slicer, which runs on 10.6 or later can do this for regular applications.
1) Run the program and select a target process.
2) Go to Tools -> Dump All Memory... This will save all the current readable memory in a directory with a bunch of files each indicating a particular memory region and a file that merges everything as well. These files can then be viewed with a hex editor.
3) There's also the real-time memory viewer in the Memory menu for looking at a particular spot.
Dmalloc - Debug Malloc Library
This program came with OS 10.6 but it seems to have disappeared with OS 10.7 (which has many, many, many ... programming complications). Excluding 10.7 regrets, Dmalloc is wonderful way to examine every memory allocation.
Ah ha...
Mac OS 10.7 provides Menu-Product-Profile. I have not investigated fully used it, however, I recognize the Dmalloc icon within it.
I've faced to a problem with a PIC Micro controller.
I have a micro-controller programmed by me long time ago and I lost the relevant source code and the schematic diagrams. Now I need to invert the value of a port. I can do this using some NOT gates but it is a big hassle to do so. or alternatively I will need to write the whole program back.
I don't expect to see the code back in PIC C or MikroC. Having an understandable assembly code would be sufficient.
So do anyone has any experience on a good HEX decompiler that I can use for this purpose? Any comments based on your experience? :)
EDIT : Device PIC 16F84A
Decompilation is unlikely to be a practical solution, and it is even less likely that a tool for your specific compiler and instruction set combination even exists.
Disassembly however is straightforward, though whether you will be able to make sense of the resulting code is a different matter since no comments or symbols are preserved in the HEX file; if you have the original object code it may render the disassembly more readable. There are many PIC disassemblers available, just Google it; I can't direct you at any specific one because there are a number of PIC families with different instruction sets, and you did not specify.
A simple approach to disassembly would be to simply load your HEX file into MPLAB and select View->Disassembly Listing, then right-click the windows and select "Output to File". This output may need some massaging for it to be suitable for input to an assembler.
I know this is an old post, but I have recently encountered a similar problem and didn't find a very complete answer online. I lost my MPLAB X IDE project due to hard drive failure, luckily I had already programmed a device with a working version of the code.
Recover the .hex
Follow the steps below to recover the .hex information from a programmed device:
Use MPLAB X IDE and your PIC programmer (I used PICkit3) to read the .hex file from the programmed device:
Start a new project for your device.
In "Project Properties" select your programmer.
Right click on the project folder and select "Set as Main Project".
Click on the arrow next to the "Read Device Memory Main Project" and select "Read Device Memory to File". Reading device memory to .hex file
Disassemble the .hex
You can view the disassembly in MPLAB X IDE, but you cannot edit or save it (or at least I couldn't figure out how to) and it is very cryptic. I found the easiest, no strings attached, disassembler to be the one packaged with gputils, it is called gpdasm. To download and install, visit the gputils page here:
https://gputils.sourceforge.io/
Now open a command prompt and navigate to the folder where your .hex file is located. Generate an assembly source file from the .hex with the following command:
gpdasm -p p16f84a -csno hexfile.hex > asmfile.dis
With the -c -s -n and -o options, this generates quite a good listing which is very near to being able to be assembled as is. Obviously the variable names and labels cannot be recovered, but at least subroutines are identified which makes things a lot easier. Hope this helps someone in the future.
There is a list of PIC disassemblers at the official PICList technical reference.
Many people never use a stand-alone disassembler, but prefer to use the disassembler inside their favorite PIC simulator.
http://piclist.com/techref/microchip/dissassemblers.htm
http://piclist.com/techref/microchip/simulators.htm
You should be able to load the hex file into the MPLAB IDE and view the assembly code from there as well as run it and step through the code in the simulater if I am not mistaken.
You can also use it to read the code from a device if it is not code protected.
A simple matter makes me suffering as I'm new to PyS60 development.
What is the IDE for
Executing program on-device with a single reasonable amount of clicks,
Typical step-into, step-over, run-to, watch (used from PC) for the on-device running program ?
Real on-device debugging is not (yet) possible, I'm afraid. You have to use popup notes, audio.say() or write to log files.
Personally I forward sys.stdout and sys.edterr into a log file and use sys.settrace() and
sys.setprofile(). Works reasonably well, no need to modify real app source code, just dump EVERYTHING into a log file and do search afterwards.