In the middle of an experiment i got stuck with an issue for which i hope somebody out here might know the solution.
I am using TIMER1 in PWM mode which is supposed be to continuously running in the background. Since triggering ADC using Timer1 update event is not possible in STM32F401, I used the following settings.
TIM1: Trigger Event Selection_Output Compare(OC1REF)
ADC1: External Trigger Conversion Source_ Timer 1 Capture Compare 1 Event
On sensing a particular value through ADC1 i need the Main output to be disable(i don't want to disable the timer) So i cleared the MOE bit in BDTR register.
But disabling the MOE bit actually stops ADC Triggering.
What could be the possible problem for ADC not getting a proper trigger when only the main output is disable and timer is still running ?
If this is not the proper way can ,what is the proper way to turn off output alone ?
Related
somehow when i am running my code, it seems like one GPIO Port isn't being initialized, meanwhile if i am debugging, it is.
I am initializing two sensors:
struct MAX31856_t max31856_temperature_sensor_heater_1 = MAX31856_TPL( SPI_DEV_TPL( IO_PIN_TPL(
TEMP_SENSOR_0_CS_GPIO_Port, TEMP_SENSOR_0_CS_Pin), &spi1));
struct MAX31856_t max31856_temperature_sensor_heater_2 = MAX31856_TPL( SPI_DEV_TPL( IO_PIN_TPL(
TEMP_SENSOR_1_CS_GPIO_Port, TEMP_SENSOR_1_CS_Pin), &spi1));
Sensor Heater 1 is not getting any Information, Sensor Heater 2 is getting Informations. Now if i swap the Name of the Heaters:
struct MAX31856_t max31856_temperature_sensor_heater_2 = MAX31856_TPL( SPI_DEV_TPL( IO_PIN_TPL(
TEMP_SENSOR_0_CS_GPIO_Port, TEMP_SENSOR_0_CS_Pin), &spi1));
struct MAX31856_t max31856_temperature_sensor_heater_1 = MAX31856_TPL( SPI_DEV_TPL( IO_PIN_TPL(TEMP_SENSOR_1_CS_GPIO_Port, TEMP_SENSOR_1_CS_Pin), &spi1));
and run the code in the debugger, Sensor Heater 1 and 2 are getting Informations.
How can this happen? I was thinking about a timing problem, but since it is working in the debugger, i don't really know what to do.
Provided that you are debugging and/or running the same binary. Debugging is mostly the same as running except if you halt the processor (es breakpoints).
In that case...
some peripherals could continue to run or be halted togheder with the cpu, the behaviour is some cases can be configured. (timers, watchdog...)
some interrupts can be lost.
some hardware buffers can overflow and data can be lost (if you don't use any flow control in your IO)
How do you run the code in debug mode? Do you have breakpoints somewhere?
You (OP) are right about it being most likely a timing problem, and probably related to physical SPI transmission. Because your line of code to send/receive something over SPI has already executed in the MCU, but physically the bits and bytes are still being transmitted on the line, while MCU is already calling the next SPI function, so one of the transmissions will fail. Try adding some delay after SPI transmission code. If things work after that, then it's the timing of SPI peripheral, and you need to add a check that there is no SPI transmission already in place before you call a functions to send/receive something.
You can do while(transmission) (pseudocode, replace with actual check if SPI transmission is going on) to wait until the previous transmission ends to call the next one.
I’m writing a low power application for the STM32F407VG. It goes into standby mode and can wake up in two ways:
Periodically, using the RTC wakeup timer;
By pressing a push-button connected to the PA0-WKUP pin.
Depending on whether the application was woken up by the RTC or the push-button, I need to perform two different tasks. Therefore, when the firmware resets after waking up from standby mode, I must figure out the wakeup reason (RTC or push-button).
I’ve made the necessary configurations to wake up from Standby mode from either source, and they’re working — the processor does wake up periodically, or when I hit the push-button. The issue is with figuring out the wakeup reason.
The documentation for the RTC_ISR register’s WUTF states the following:
Bit 10 WUTF: Wakeup timer flag
This flag is set by hardware when the wakeup auto-reload counter
reaches 0.
This flag is cleared by software by writing 0.
This flag must be cleared by software at least 1.5 RTCCLK periods before WUTF is
set to 1 again.
This seems perfect to me — if the flag is set, it must be because the wakeup timer reached 0 and woke up the processor.
I inserted some code at the beginning of my firmware to read WUTF and set an LED according to it, and then clear the flag immediately after that. Unfortunately, this flag is always set, not only when waking up from Standby mode due to the RTC, but also when waking up due to the push-button, and even when powering on the circuit for the first time.
I checked the errata sheet for this MCU and found no mention of this issue.
I do realize a workaround would be to read the status of the push-button, and if it corresponds to the pressed state, assume the wakeup reason is due to the push-button being pressed. However, my firmware runs for only a couple of microseconds in Run mode before going back into Standby mode, and due to bouncing issues with the push-button, this kind of detection is not reliable unless I stretch out the Run mode time to several microseconds. This in turn impacts the average power consumption of my application (and therefore battery life). While adding a capacitor might help, I’d like to implement a software-only solution if possible.
It was entirely my bad. I was reading the flag through the following HAL macro:
__HAL_RTC_WAKEUPTIMER_GET_FLAG(&hRTC, RTC_FLAG_WUTF);
It turns out I was using it before initializing hRTC.Instance, so rather than accessing the RTC's registers, it was just reading some random memory (probably address 0). After fixing it, the flag appears to work reliably.
I am using the internal oscillator (FOSC = 7.37 Mhz) of the dsPIC33EV256GM102. I have a 1602 LCD connected to the PIC via 4 data, and enable, RW, and RS control lines.
I write initialization commands to the LCD and then two lines of text. That works fine.
After 2 minutes and 10 seconds the enable line quickly pulses high-low causing something to be written to the LCD. It happens again in another 2:10 and then again, repeatably.
All my program does right now is initialize the LCD, write two lines of text and go directly into a while(1).
I have tried setting the LCD enable low on every iteration of the While. I have tried latching the enable low before going into the While. I have moved the enable to another pin but the pulse still occurs on that pin. If I remove the enable line after writing the data, the problem goes away.
Any thoughts what might cause this kind of behavior or what additional troubleshooting steps I might take?
I am using pin 24 labeled RPI45/PWM1L2/CTPLS/RB13 for the enable but I have also tried pin 23 labeled RPI44/PWM1H2/RB12. I am not executing any code related to peripheral pin select yet.
When I download the program via the Pickit3, for the first POR while the Pickit3 is still in the circuit, there is some spurious text written to the LCD. So I have to disconnect the Pickkit3 and do another POR before the two line of text are written correctly without any unwanted additional data writes.
In conclusion there are two issues really or perhaps they are related?
I have function that prints debug output to UART. If interrupt occurs when this function works, then debug output from interrupt break previous debug text. So I have something like this:
"03:32:46 Loading data fr03:32:46 Button pressed".
I consider some solutions. I prefer not disable interrupts, instead of it disable debug output if it breaks other debug print function.
What is the good way for solving this problem?
Basically don't do print statements in an ISR as this will have influences on the performance. If you want to know if an ISR was called (e.g. via a button press), try to this by setting output pins and toggling attached LEDs.
Use ISRs to set flags or perform short calculations.
I use PIC18F6622 and PICC compiler.
I use the Watch Dog Timer to regularly wake from sleep mode. The data sheet states that watch dog fire during power-managed modes exits the mode and usually it works just fine.
However, sometimes I see an unexpected reset. Using PICC's reset_cause() I found that the reason is WDT_FROM_SLEEP. What does that mean? Why is it causing a reset instead of wake-up??
Thanks a lot,
Lkanab.
An interrupt event may have woken the PIC up, then the WDT probably overflowed during run mode, which would cause a watchdog reset.
You are entering your MCPU into SLEEP mode.
In this mode the MCPU wait on event to wake-up form sleep.
You didn't explain what kind of events/interrupts are enabled before your program go into SLEEP mode.
Let say if you are waiting on OnPinChange (EEPROM write, ADC conversion ...) event and that is never heppend (or to late) so the Watch Dog time expire and reset the MCPU.
One solution: try to increase the Watch Dog Timer time interval.