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.
Related
Upon instantiating a LowPowerTimer, like so:
LowPowerTimer* lowPowerTimer = new LowPowerTimer();
It crashes on my own target. It works 100% on the STM32F429-discovery evaluation board.
What could cause the problem? All other code runs perfectly. There are enough memory and flash. The micro is of the same family. Are there any prerequisites that I do not know of? The micro I'm using is the STM32F413RH with a 26MHz external crystal.
I use the mbed platform and code in C++, FWIW...
My first guess would be that you have not configured the lpticker clock source correctly. Do you have the same crystals as the evaluation board? See which clock source the lpticker is using there and see if it's missing on your final board.
In addition, what is crashing? Do you see a hard fault? Where does it originate from?
So what I found was that in the targets.json file I had to override the lse_available macro. The lse_available macro states that a low-speed external oscillator is connected to the micro - and then the Low Power Ticker would use that as its source. But if you set it to 'not connected', it uses other clock sources.
I am doing an academy project about porting Autosar OS to a microcontroller. After reading papers and information about Autosar, Arctic Core and Arctic Studio, I have some questions:
I used to port FreeRTOS to a microcontroller and it's very easy, I just included some *.h and *.c files of FreeRTOS, and then used the FreeRTOS functions to build my application on the chip. Can I do similarly to Autosar? If it is possible, which files should I include to my main.c
Second question, in FreeRTOS, I only need to use xcreatetask() function(this is a FreeRTOS function) to set task priority, and then i applied vstarttaskschedule() function to run the task in queue however I cannot see these kinds of functions in Autosar OS. Can someone tell me which function in autosar have same functionality like functions I said.
When I program Texas Instrument chips, there is always main function which include the main program that we will build for the chip. However, I don't see any main functions in arctic Core example. How can the chips runs the program without main function?
Please help me answer these questions!
3, You are not able to see to main function in ARTIC core:
AUTOSAR does not define start-up code. You are expected to write main function yourself. Kernel in AUTOSAR OS gets initialized from ECUM module. If you want to boot your OS, you must have ECUM module. Also you should have BSWM module to start schedule tables. You have to create rule in BSWM for RTE start-up and it will start your schedule table.
You have to handcode start-up code (RAM/Register/etc initialization), from that you have to call main function, main function will be handcoded. Call EcuM_init from main function. This way your OS will boot.
2, You are not able to locate function to set task priority and activation:
AUTOSAR does not support dynamic task priority. You have to set all priorities in cofiguration. To run task you can use ActivateTask(). One quick trick to start task at startup is, set parameter OsTaskAutostart for one task. Task for which you have set parameter OsTaskAutostart will get invoked as soon as kernel is initialized.
Your start-up code will be target specific.
ECUM does the initialisation part for all the SW modules within ECU.
Remember to call ECUM from your Main.c
ECUM does initialisation of BSWM, Drivers and the SW modules.
Once RTE is initialised - there is a part SchM within the RTE which schedules the Mainfunctions from each module.
The Mainfunctions from each SW Module are known to RTE by BSWMD and SWCD files.
Read RTE SWS, ECUM SWS, SYSTEMTemplate SWS for more info
I guess your academic project already ended, however porting an AUTOSAR OS to a specific microcontroller is not a suitable scope for an academic project.
Firstly, from your question, I cannot tell if the OS is ARCCORE or other. Secondly, from my experience with FreeRTOS, there is only a limited amount of knowledge which applies to AUTOSAR OS and creating tasks (2.) is application-level rather than porting. Thirdly, the majority of AUTOSAR OS rely on specialised embedded compilers, e.g. GHS or DIAB which are not home to academia.
I have not ported AUTOSAR OS myself, but I suggest taking a look at a ported version, the architecture and file structure, system and then the start-up routines, vector tables, peripheral code, etc. Complexity might be reduced when porting within the same MCU architecture, say Renesas machines or ARM.
To answer your question 3., you will not find the main() within the ARCCORE examples. main() is located in os_init.c and looks like this:
extern void EcuM_Init(void);
int main( void )
{
EcuM_Init();
}
Then, EcuM_Init() [EcuM.c] calls InitOS();
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.
Is there a way to make the bootloader code occupy a specific section in program memory?
I noticed that some of the code is written in the top section of memory but the other part is written starting at section $11000. In my case it conflicts with my application code. So how do I force the bootloader code to occupy program memory starting from $00000 to $10000? I am assuming it can be done by changing some settings under Mplab XC8 compiler.
PIC: PIC18F87J11
Compiler: MPLAB XC8
Update:
Found the fix
Project properties > XC8 global options category > Memory Model > ROM ranges
ROM RANGE: 0-10000
Update:
I am seeing another issue though.
So I set the ROM range from $00000-$10000, but that's not enough space for the bootloader code even though it should. However when I look at the program memory under MPLAB XC8 after building the project, I noticed that there are some addressees left empty.
How do I force those addressees to be used? If those sections were used then the specified ROM size from 0-10000 should be enough for my bootloader code.
For example those addresses are used (data written there)
00000-0925C
But then these address are not used, just left blank
0925E- 0F77A (huge section, what a waste)
Then these addresses are used
0F77C-0FFFE
But then my program gets cut off at $10000 even though there seems to be more code to be written to memory.
So
How do I force those unused addressee to be used? Its just a huge waste of memory to skip them and I don't understand why they are empty. I can not give the Bootloader anymore ROM space, the rest must be given to the Application Code.
I hope everything is clear, thanks!
To place the bootloader in the specified memory, you should:
1) In the code - create the section.
int __section("_bootloader") helper(int mode) {
/* ... */
//bootloader functions here
}
2) In the options of linker - add options to place the section to the specified memory.
-L-A_BLOADER=00h-ffffh
-L-p_bootloader=_BLOADER
To see the exect functions placed in the memory range 0F77C-0FFFE, you may see the *.map file (if it is generated).
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.