I am new to ARM programming and started out with NXP's LPC2148 chip. I am using it's on chip ISP UART bootloader. The loading was working perfectly at 9600 baud with 8 bits and even parity.
Then I flashed a code made by a new project on LPCXpresso through the Flash Magic firmware at 14400 baud. After that the bootloader sequence does not work anymore. I have tried every possible baud rate with odd and even parity but it doesn't work anymore. The common problem saying "Autobaud failed" is coming up and weirdly the chip is warming up a bit when the power is on.
The worst question that is hitting my head is whether I wrecked the ISP bootloader.
PS. I have been using a 16MHz crystal. Although the code that I inserted in it was actually made for a 12MHz crystal with PLL adjusted at 5 multiple (60MHz). But the bootloader initializing sequence should bypass the normal code on chip isn't it?
Please help me
Related
I am trying to add a simple led application to a PIC18F25Q10 in another circuit using the Curiosity HPC development board. I am using the MCLR, PGD, PGC and GND pins. Although I set the LVP mode to enable in the CONFIG settings and the program speed to low in the project properties, MPLAB " MPLAB has detected that the undervoltage configuration bit on the device is off and you have selected" error output . I also cannot connect to the PIC.
My MPLAB version is 6.5
I am using the X8 compiler (2.40).
I am throwing code with PKoB4.
I checked my circuit connections and confirmed that the MCLR, PGC and PGD pins were correct, but I kept getting errors.
I have done the steps to be applied here, but I have not reached a result. I cannot connect to the PIC.
Connecting to MPLAB PKoB4
Currently loaded versions:
Application version...........00.05.79
Boot version..................01.01.41
Script version................00.05.35
Script build number...........86fedc5c2e
Tool pack version ............1.8.869
Target voltage detected
MPLAB has detected that the low voltage configuration bit on the device is off and you have selected the low voltage programming option on the debug tool's property page. If you wish to use the low voltage programming option you must first do the following:
* Turn off the low voltage programming option on the debug tool's Program Options property page
* Program the low voltage configuration bit to on
* Turn on the low voltage programming option on the debug tool's Program Options property page
Connection Failed.
I checked the forum pages and updated MPLAB and the PKoB4 drivers to test the information that it might be version related, but I could not connect to the PIC.
I used another circuit because I thought there would be a problem with the PIC. I got the same error. I tried to load the code from another computer and I continued to get the same error.
I tried to code with ICD, it codes. However, I could not solve this error on the Curiosity HPC development board. I came across some information in the Curiostiy development board user's guide.
information Image..
I need to be able to connect to the PIC and throw code. I am curious about your thoughts and advice about my problem.
According to the advise of MPLAB your PIC chip has programmed to have LVP disabled. The curiosity boards has a built-in PICKIT which can program only in Low Voltage Programming mode. So you have to do the following steps:
Get a standalone PIC (i.e. PICKIT3) programmer
In config settings of your PIC set the LVP to be on
In MPLAB IDE, File > Project Properties > PICkit 3 > Program Options make sure that Use low voltage programming mode entry option is unchecked
Burn your PIC device with this configuration once using the standalone PICKIT programmer
These steps will prepare your PIC so that it can be programmed in curiosity board. Once you done with all steps correctly, you will be able to burn your programs using your curiosity.
When you program with the built-in programmers, you always wanna make sure that your PIC is programmed before with configuration LVP = ON. And also keep this config bit always ON as long as you keep programming it in a curiosity board.
One more thing to tell, MPLABX is automatically checks the Use low voltage programming mode entry option when you select the Connected Hardware Tool as your curiosity board.
Go ahead and try the steps and then let me know if I could help any further.
Dears,
I am newbie in embedded systems.
I have downloaded code examples from st.com written for target device STM32F072B. As I am using Nucleo-64 with STM32F030r8 MCU, I need to convert the downloaded code examples to support my target device STM32F030r8.
I can build the code examples (written for STM32F072B) in Keil, but when I am changing the target device to STM32F030r8 I am getting an error:
..\system_stm32f0xx.c(301): error: #20: identifier "RCC_CFGR_PLLSRC_HSI48_PREDIV" is undefined
Please help me either by telling the way to convert the downloaded code examples to support my target device STM32F030r8.
Regards
Niyas
Welcome to the exciting world of embedded systems where peripherals even change within sub-families of devices.
The missing macro your compiler complains about is actually a pretty good hint on whats wrong. Looking at the STM32F072B reference manual ST lists the following available clock sources:
Various clock sources can be used to drive the system clock
(SYSCLK):
HSI 8 MHz RC oscillator clock
HSE oscillator clock
PLL clock
HSI48 48 MHz RC oscillator clock (available on STM32F04x, STM32F07x and STM32F09x devices only)
Comparing that to the STM32F030 reference manual we can see that the HSI48 clock is clearly missing on this device.
Various clock sources can be used to drive the system clock
(SYSCLK):
HSI 8 MHz RC oscillator clock
HSE oscillator clock
PLL clock
I guess that some part of the code snippet you downloaded tries to use that missing HSI48 clock somehow. Switching the device inside the IDE most likely caused your project to use another device header where the macro "RCC_CFGR_PLLSRC_HSI48_PREDIV" simply isn't defined. You might be able to use another clock source instead, but your question doesn't contain enough information to answer that for certain.
Generally when working with embedded devices you have to be very careful when switching from one microcontroller to another. Even the tiniest differences (even a single register or a single bit) can break your build or even worse your hardware.
Thank-you Dears,
I found the answer. Guillaume Petitjean 's reply made me to read more documents and finally I made it.
Question:
The STM32SnippetsF0 (C-code examples) downloaded from https://www.st.com/en/embedded-software/stm32snippetsf0.html#overview is designed to run on the STM32F072B Discovery board. So changing target device(my case STM32F030r8) need many changes like adding supported header files etc.
*I got the mentioned error previously because I compiled simply after changing target device in setting but without adding proper header file. :(
*I was asking this. Don't know whether I asked properly. Anyway the solution i found is sharing with you all.
Answer:
This document tells how the snippet code can be used on other target device
https://www.st.com/resource/en/data_brief/stm32snippetsf0.pdf
After reading the document and adding necessary driver header files I am able to compile and build the code
Context
I have accidentally uploaded some ARM Cortex M0-cmis files (core-cmFunc.h and core_cmInstr.h) to the STM32F407VG discovery board. After I noticed my mistake, I tried to undo it by changing my code and upload it again... but it said it couldn't make connection.
What I already tried
I've tried to get passed the USART interface of the discovery board by uploading the code directly on the ARM Coretex M4 chip via the bootloader. I connected BOOT0 to VDD and PB2(=BOOT1) to GND so the chip starts up in the Pattern1-mode. Then I connected PA9(=Tx) and PA10(=Rx) to an USB to TTL cable (by the use of a RS-232 chip in the cable) and reset the device. I started the "Flash Loader Demonstrator" from ST to make connection with the board (I've done this before and it worked). But that didn't made connection either.
Extra information
The Windows filemanager "sees" the ARM Cortex M4 file when it gets connected to the PC;
Led LD7 emits green light when the board is powered;
Led LD1 emits red light;
Does someone knows how I can factory-reset the flashmemmory of the STM32F4 so it acts at it should again?
After some trial and error I've come to the conclusion that I accidentally activated the OTG_VBUS with my code. I couldn't upload another code because that bus was active on PA9(TX of USART2). It seems that the VBUS was held active, even in bootloader mode.
PA9 connected to VBUS
The solution to this problem was the use of another bootloader interface, I used USART3 on PB10/11, but you could also use PC10/11. After I uploaded a dummy code in that manner, I
was able to upload codes with the Coocox-IDE again.
Other Bootloader interfaces
I have tried a simple Blinking LED program on my STM32F4 Discovery board by following this tutorial.
However, I am not sure how to stop this from running, i.e., when I unplug the device from the PC and plug it in, I would expect it to reset itself (I might be wrong too, please correct me if this is not the case).
The board keeps blinking the LED on connecting it again. How do I reset it to its original state? Pointers to references for embedded programming would also be helpful.
If "original state" means the program that was shipped with the board, then you can probably download that at ST's website. You'll need to program the chip's flash with that stock binary.
Note that by programming the board you're programming the flash memory which will retain its contents through power cycles.
I´am working in a project with the atmel atmega8a MCU. I´ve designed a code that works with an external 16MHz crystal. For that reason i burn the atmega8a´s fuses with the AVRISPmkII programer (HIGH FUSE:C9 LOW FUSE:FF) for a external 16MHz crystal. I test the functionality of the system with a atmega8a PU and this works perfectly. Now i´m trying to do the same in a PCB with the atmega8a AU but the burn fuses process don´t work in the same way. After this process the atmega8a AU MCU doesn´t work again and the programer can´t recognize it.
It´s something different in the burn fuses process between the atmega8a PU and the atmega8a AU?
anybody knows why happens this???
I hope you can help me with this trouble.
I´ll been waiting your answer.
Thanks a lot.
Take a fresh ATMEGA8 controller(1 MHZ internal default clock frquency).
Now write a program just to make a PIN high and low without any delay.
Such as pin 14 gives high low pulses. Then connect pin 14 to that ATMEGA8 controller which you are unable to reprogram .
Then see the magic.