Well, I'm using Code::Blocks as the IDE, and Win AVR as the compiler.
F_CPU is selected as 8000000UL.
I'm writing code for Atmega32.
But when I run my written code (*.hex file) in Proteus design suite (ISIS) the _delay_ms(1000) doesn't give a delay for 1sec. I don't know if it is write or wrong, I've selected CKSEL fuses to be (0100) Int.RC 8MHz in edit component.
What's wrong?
please....
Have you tried setting the compiler optimization to something other than -O0? From the avr-libc docs regarding delay* functions.
In order for these functions to work as intended, compiler
optimizations must be enabled, and the delay time must be an
expression that is a known constant at compile-time.
Using PWM for servo control I figured out that even with this setting of Internal 8Mhz, Proteus are actually simulated with a clock of 1Mhz. If you change F_CPU to 1000000UL you will see that delay will work just fine.
Its just proteus simulation lags. On the real device your delay function will work properly. In order to simulate time delays the good choice is using avr studio program.
Related
I just started with microchip world.
I'm about to buy a PicKit3 and i've seen it can outputs from 1.8V to 14V MCLR.
The pic i will use is the PIC16F1829 and it should work with MCLR # 5V.
In the datasheet it seems i would need a zener/shunt to limit the voltage.
First of all isn't there a board ready to play with?
Can i use LVP? If so using MPLab 8 IDE how do i change in LVP?
Is the pin connection the same?
Since i haven't bought it yet i would rather avoid burning a pic
Regards,
Notes at the bottom of page 345 in the PIC16F1829 data sheet (DS40001440E) recommends using a voltage limit circuit when using the ICD2 device programmer.
According to Microchip this is "not required" when using the PICkit3.
Get a few extra PIC16F1829 just in case.
You ask about boards ready to use, take a look at the Curisotiy Nano boards
https://www.microforum.cc/topic/9-microchip-xpress-evaluation-boards
These are ready to use and do not need any programmer. You can simply send a file to these devices over USB. They are also have debugging capability.
In terms of the 14V on MCLR, the device is designed to handle whatever pulse will be generated by the PICkit3, so you do not need any protection for the PIC against that. In fact limiting the voltage on that pin will prevent the device from programming so you definitely do not want to do that. If you are however using this pin to connect to other parts on your board the other parts probably will need protection.
You can most definitely use LVP, just be careful, it is possible to use LVP to disable LVP, and then the only way to get it back on is to use HVP!
Lastly in the IDE under programming options you can change the mode there (Use low voltage programming mode entry)
In the IDE i've set the voltage appropriately and everything went ok on its own.
I didn't have to enable anything fancy
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)
I am programming on Arduino boards that have several serial ports (let us say for now Serial, Serial1 and Serial3). Each port is a separate object. For using a port, one needs to first initialize it with the begin() method (what I mean with need here is, to get it working fine). The problem is that, the corresponding objects are all available in the Arduino IDE by default, even if you do not declare / initialize them in your sketch, so one is not required to call the constructor and / or initialize a serial port for using it (what I mean here with required, is what should be done to avoid a compiler error). As a consequence, the following kind of code compiles fine, while there is a typo:
byte crrt_char;
void setup(){
Serial.begin(115200);
delay(100);
Serial.println("booted");
Serial3.begin(57600);
// Serial1.begin(9600);
delay(100);
}
void loop() {
if (Serial3.available() > 0){
crrt_char = Serial1.read();
Serial.println(crrt_char, HEX);
delayMicroseconds(5);
}
}
(it should be Serial3 instead of Serial1 in the loop).
I have been bitten by this kind of bug and lost a lot of time debugging (in a more complex code of course) several times, and find it sad that the compiler does not save me (for me it looks like a job for a compiler to check for this kind of typo, isnt't it?). Any way I could get some compiler help for detecting this kind of error?
The Arduino core is available here:
https://github.com/arduino/ArduinoCore-avr
Would a possibility be to write my own Arduino core / variants without the serial ports pre-declared, so that I would need to declare them myself before I can use them?
While it may seem unfair, what the compiler is doing is correct. The compiler must compile the code the way you have written it.
Though people get confused between the job of code assistance vs the job of code compiler, It's your job to ensure that the code is written correctly. It's the compilers job to confirm if the code follows proper syntax.
As for making a board variant and including it into an Arduino Core, you will have to make changes to the HardwareSerial.h file, to ensure that any un-necessary serial objects are not declared.
An easier solution would be to make a macro hold the Serial object you want to use like so
#define CONTROL_PORT Serial
#define COMMUNICATION_PORT Serial3
And in your code use CONTROL_PORT and COMMUNICATION_PORT in the following manner
CONTROL_PORT.begin(9600);
COMMUNICATION_PORT.begin(9600);
With this, you will never face a typo, and you can change Serial1 to Serial3 whenever you want.
I hope this helps.
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 using the MSP430F2013 processor for an application, which doesn't have a UART. I need a UART, and so I used the TI's sample code "msp430x20x3_ta_uart2400.c" to emulate one using the Timer module. This all worked fine (compiled with IAR Embedded Workbench), having tested it using PuTTY to transmit characters to a development board and a loopback to echo them to the terminal.
That was a de-risking exercise, and now I've come to port that code into my application's state machine. Having done this, I'm having issues surrounding the timer interrupts and low power sleep modes. Here's the snippet of my code around the entry into the low power (sleep) mode:
// Prepare the UART to receive one byte.
prepare_receiver();
// Enter low power mode 1.
__bis_SR_register(LPM1_bits + GIE);
// Check whether the full message has been received.
if(true == get_message_complete())
{
process_event(e_euart_message_received, NULL);
}
What I'm seeing on the debugger (C-Spy) is that sometimes it will execute the bis_SR_register() line on first entry and then go to the if statement, i.e., ignoring the fact that I've asked it to go to sleep. On other occasions, when it does go to sleep when it should, the ISR triggers correctly and eventually brings me back to the if statement to continue program execution (as I'm expecting). However, if I try to step to the next statement, the application freezes on that first line, i.e., I can't advance.
I can't think of anything functionally different from TI's example that I'm doing, so I figure my problem must be something to do with how I've ported it. For example, my Timer ISR and the code I've posted here are in different compilation units - would this sort of decision have any bearing on things? I'm aware my question might be a little vague but unfortunately I can't post all of my code, so instead I'm looking for someone with MSP experience who might be able to suggest some things to look at or some potential pitfalls that I may have fallen into.
Debugging interrupts with C-Spy in Low Power Mode is going to be tricky. According to Section A.3 Debugging (C-Spy) - IAR User's Guide:
5) C-SPY can debug applications that utilize interrupts and low power modes
But there are some "gotchas" that you should be aware of that may be causing your headaches.
In particular:
14) When C-SPY has control of the device, the CPU is ON (that is, it is not in low-power mode) regardless of the settings of the low-power
mode bits in the status register. Any low-power mode conditions are
restored prior to Step or Go. Consequently, do not measure the power
consumed by the device while C-SPY has control of the device. Instead,
run your application using Go with JTAG released
19) C-SPY utilizes the system clock to control the device during
debugging. Therefore, device counters, etc., that are clocked by the
Main System Clock (MCLK) are affected when C-SPY has control of the
device. Special precautions are taken to minimize the effect upon the
Watchdog Timer. The CPU core registers are preserved. All other clock
sources (SMCLK, ACLK) and peripherals continue to operate normally
during emulation. In other words, the Flash Emulation Tool is a
partially intrusive tool.
Devices that support clock control (Emulator
→ Advanced → Clock Control) can further minimize these
effects by selecting to stop the clock(s) during debugging
24) Peripheral bits that are cleared when read during normal program
execution (that is, interrupt flags) are cleared when read while being
debugged (that is, memory dump, peripheral registers).
When using certain MSP430 devices (such as MSP430F15x, MSP430F16x,
MSP430F43x, and MSP430F44x devices), bits do not behave this way
(that is, the bits are not cleared by C-SPY read operations).
26) While single stepping with active and enabled interrupts, it can
appear that only the interrupt service routine (ISR) is active (that
is, the non-ISR code never appears to execute, and the single step
operation always stops on the first line of the ISR). However, this
behavior is correct because the device always processes an active and
enabled interrupt before processing non-ISR (that is, mainline) code.
A workaround for this behavior is, while within the ISR, to disable
the GIE bit on the stack so that interrupts are disabled after exiting
the ISR. This permits the non-ISR code to be debugged (but without
interrupts). Interrupts can later be reenabled by setting GIE in the
status register in the Register window.
On devices with the clock control emulation feature, it may be possible
to suspend a clock between single steps and delay an interrupt request
(Emulator → Advanced → Clock Control).
One thing to try is commenting out all the low power code and seeing if your UART code works like that. Then go back and try re-enabling the low power mode.
The answer to this question lies in the debugging setup and more specifically what types of breakpoints are being used. I had quite a complex series of macros that were running on program upload, which set various hooks into memory for testing purposes. These hooks relied on software breakpoints being created, which would then call functions outside of the application. I have seen no problem in using these breakpoints in normal use, however their existence means that the debugging session doesn't run in real-time (i.e., the device is under control of the host PC). This, for a reason yet not completely known to me, caused problems when trying to debug interrupts and low power modes. (I suspect that if I was to look a bit deeper, I would see the need to use clock control whilst debugging, but I'll save that for another day).
So, to solve this problem and allow me to debug my interrupt and low power mode heavy code, which I'd ported into my larger application state machine, I had to do the following:
Disable software breakpoints within IAR.They're not actually enabled by default, but if you've been doing clever things with macros like I had, you probably would've needed to enable them, since there just aren't enough hardware breakpoints available in most MSP430s (for instance, I only have two in the MSP430F2013, and C-SPY more often than not hogs one of those!). The obvious downside to this is that debugging becomes a bit more laborious, but at least it's reliable.
Remove links to .mac Macro files.In other words, if you're using macros, don't. In my case, this meant that I had to hack some state machine logic in order to force myself down a certain route (that previously the macro had been doing for me). This clearly isn't ideal, but it will allow you to debug the interrupt/low power mode code. The macros can then be re-enabled afterwards.
So it turned out that there wasn't a problem with my port after all. I'm not particularly happy with this hacky solution, but at least it's a step forward. If I have the time, I'll investigate to see if I can work out a way of using software breakpoints and add to this answer.