Currently i am trying to get the STM32F405 to jump to bootloader from application code without the use of the boot0 and boot1 pins.
I did already try multiple things to get that done but it always ended with the the firmware jumping to the bootloader (at least it seems like it) and after approximate 18 seconds the firmware restarts (no Watchdog or similar things that could wake the chip up again are used as far as i know).
During those 18 seconds if i try to update the firmware the bootloader doesn't get found.
I tested things like:
1. (STM32F4 Jump to Bootloader via SoftReset and without BOOT0 and BOOT1 Pin)
Set a value in SRAM
Restart the STM32F405 with NVIC_SystemReset() to get the STM32F405 to close reset condition
Check for value in SRAM ( if it's set do the following )
Move stackpointer to bootloader address
Jump to bootloader address + 4 (0x1FFF0000 + 4)
2.
During runtime call function JumpToBootloader()
Within that function disable interupts, reset SysTick, reset SYSCLK, call RCC_DeInit()
Move stackpointer to bootlader address
Jump to bootloader address + 4 (0x1FFF0000 + 4)
One approach i found but couldn't test yet was to do basically what i discribed in try 1. but using assembler code within the STM32F4xx startup file.
The problem here is that the tutorial i found uses the KEIL assembler syntax which i cant use because i use the Atollic TrueSTUDIO and i have not enough knowlege about assembler to change the KEIL syntax to standard assembler syntax.
The thing that confuses me the most is that in an other project i use an STM32F3xx (cant remeber the correct number) and i do basically the same thing as in try 2. but with the the bootloader address of the STM32F3xx (0x1FFFD800) and it works perfectly fine and i can update the firmware via USB.
So the questions i have:
What could i try next to get the bootloader running?
What could be the cause in my current situation for the firmware to restart after X seconds?
A few days ago i found the cause of the problem i had.
Within the "system_stm32f4xx.c" the I2S clock got configurated and in my project that clocks doesnt get used.
Im not 100% sure why, but after removing this block of code everything works perfectly fine.
(sorry for late answer, kind of forgot about the post :D)
Related
I am a beginner in embedded programming and developing bootloader in SAMD10 using Atmel studio 7, I generate Flash read/write/append programme using atmel start website which is taking space of 0x1500 but available memory is only 0x300 for bootloader so I want to optimise it.Can any one suggest me how to write.
0x0300 bytes = less then 1Kb of code. It is possible to do a simple bootloader but if yours is too complet it may never fit.
I could help and at least tell you if it COULD fit in there if you post your source code of the features you want in the bootloader. Short story : If you want anything else then a simple bootloader then it won't fit in such a small space.
You could also use a part of the program memory ( outside of the bootloader memory ) to store a routine or two and call them from the bootloader. For this you must know what you are doing because reprogramming the program will likely erase these functions if you don't make things right. If you don't know how to do it, I'm not sure you should try it. On a commercial device, doing this wrong may brick your device which wouldn't be upgradable with the bootloader anymore. It CAN be done safely if you know what you're doing, I've done similar things a few times with no problem.
A simpler method if you don't want a part of the bootloader in the program space is to add a feature in the program itself that allows a firmware upgrade. Just put your bootloader source code in the program and you're done.
I have been working with ATmega128 and other such series for about 2 years and used a UART library for serial transmission. I am pretty sure the library is correct because I have used it hundreds of times but from the past few months I cannot do UART on my ATmega128. I am sure that my hardware is correct, I am sure of my code and to add to it, the same hex file runs good in other two ATmega boards but not in other boards.
PORTs are giving 5V output when all pins coded to give output.
Statements execute before any UART function occurs and after that it stops (does nothing, no UART, not even statements after UART)
I tried copy pasting UART code completely in main.c and it worked then.
Please help! I have no idea what is going on.
Well, after a lot of tussle, I finally found the problem and solved it. When I checked the fuse bits of the other microcontroller (the working one), I found Extended Fuse bits different from the not working microcontroller. I changed the Extended Fuse bits to 0xFF and problem solved.
I am writing a basic check-pointing mechanism for ARM64 using PTrace in order to do so I am using some code from cryopid and I found a TRAMPOLINE_ADDR macro like the following:
#define TRAMPOLINE_ADDR 0x00800000 /* 8MB mark */ for x86
#define TRAMPOLINE_ADDR 0x00300000 /* 3MB mark */ for x86_64
So when I read about trampolines it is something related to jump statements. But my questions is from where the above values came and what would the corresponding values for the ARM and ARM64 platform.
Thank you
Just read the wikipedia page.
There is nothing magic about a trampoline or certainly a particular address, any address where you can have code that executes can hold a trampoline. there are many use cases for them...for example
say you are booting off of a flash, a spi flash, running at some safe rate so that the chip boots for all users. But you want to increase the rate of the spi flash and the spi peripheral does not allow you to change while executing code. So you would copy some code to ram, that code boosts the spi flash rate to a faster rate so you can use and/or run the flash faster, then you bounce back to running from the flash. you have bounced or trampolined off of that little bit of code in ram.
you have a chip that boots from flash, but has the ability to re-map that address space to ram for example, so you copy some code to some other ram, branch to it that little bit of trampoline code remaps the address space, then bounces you back or bounces you to where the flash is now mapped to or whatever.
you will see the gnu linker sometimes add a small trampoline, say you compile some modules as thumb and some others for arm, you no longer have to use that interwork thing, the linker takes care of cleaning this up, it may add an instruction or two to trampoline you between modes, sometimes it modifies the code to just go where it needs to sometimes it modifies the code to branch link somewhere close and that somewhere close is a trampoline.
I assume there may be a need to do the same thing for aarch64 if/when switching to that mode.
so there should be no magic. your specific application might have one or many trampolines, and the one you are interested might not even be called that, but is probably application specific, absolutely no reason why there would be one address for everyone, unless it is some very rigid operating specific (again "application specific") thing and one specific trampoline for that operating system is at some DEFINEd address.
I want to intercept some interrupts in the kernel, and just wrap the original function with some of my code. Mainly for learning purpose.
I already know how to intercept page-faults, and double-faults, through the IDT (Interrupt Descriptor Table), and it works just fine.
So now I want to intercept the RTC, which is at IRQ 8. I didn't find anything specific, but after reading some code I think that the IRQ is inside the IDT, and that it starts at the 32th entry (in code IRQ = IDT+32;). So I ran an example where I changed the 40th entry of the IDT, and nothing happened. (just in case, I ran it again while changing the 0x3a entry, even I'm pretty sure it's in decimal - nothing happened.)
So my questions:
Am I right that IRQ = IDT+32? (If not, where is the table that dispatches IRQs?)
Am I right expecting a kernel crash after intercepting the RTC? (I just redirect it to a function that just prints 'Hello, World!')
In case it matters, my test are run inside a VM. I run linux Mint on a 64 bit machine (gust & host). The host has Windows 7.
I am having an odd problem with my PIC16F88. I have an EEPROM connected thru I2C and it works flawlessly until I write to portb.bit6. From that point on, I start getting garbage from my EEPROM. I tried explicitly disabling Timer 1, which uses portb.6 for oscillator-out but that did not help. I tried cutting the trace from the PIC pin (pin 12) so that there is nothing physically connected to it and that did not help. My C code is simple, either portb.6 = 0 or portb.6 = 1. Either way, reading the EEPROM thru I2C fails forever more. The generated ASM code looks fine. The problem occurs on every board that I have tried it on, so it is not localized to one PCB. I am mystified. Any suggestions?
It turns out that it is necessary to write a zero bit to the SCL and SDA pins every time before writing to any bit in portb. FWIW, I was bit-banging rather than using the SSP peripheral of the PIC16F88 for the I2C communicaitons. Thanks to the people on the Yahoo group, Electronics_101, for figuring out this puzzle.