I'm programming the Atmega64M1. The access on the EEPROM is described in the datasheet, and I have no issues writing it or reading it.
In the datasheet it is said to wait for completing of previous write before reading or writing the eeprom :
{
/* Wait for completion of previous write */
while(EECR & (1<<EEPE))
;
/* Set up address and Data Registers */
EEAR = uiAddress;
EEDR = ucData;
/* Write logical one to EEMPE */
EECR |= (1<<EEMPE);
/* Start eeprom write by setting EEPE */
EECR |= (1<<EEPE);
}
My question is : is there a chance that the while loop doesn't stop ? The EEPE bit is supposed to be cleared by hardware, but is it a good practice to add a software verification to make sure that we eventually exit the loop ?
Something like:
int i = 0;
/* Wait for completion of previous write */
while((EECR & (1<<EEPE)) && (i < 100))
{
i++;
}
Related
I'm trying to understand how the STM32F091VB manages the send of data via serial protocol with the function HAL_UART_Transmit_IT()
At the moment I've a function called in the main() that creates the packet and send it via serial; it is something like this:
tx1[0] = STX;
tx1[1] = 0xFF;
tx1[2] = 0x80;
tx1[3] = 0x80;
DE_TAST_HIGH;
HAL_UART_Transmit_IT(&huart3, tx1, 8);
Now, the data I'm sending is quite small so the code run pretty fast and I'm trying to understand what's going to happen if I try to send a huge packet via serial protocol.
For istance, if my tx1[] is 100byte the HAL_UART_Transmit_IT() function block the CPU waiting while the full packet is sent to the serial port or it works more like a separate process where I tell the micro to send that packet and, while sending it it also process the remaining part of my code/main function?
I've tried to search on the micro datasheet to see if there was something about this process but I had no luck. I've read the stm32f0xx_hal_uart.c and it confirms that it is sent via interrupt in a non blocking mode but I would like to have some more in depth documentation about it
First of all you need to understand how the HAL_UART_Transmit_IT is meant to be used. We can get some help from STM FAQ.
The function is "non blocking" because when you call it it will do some configuration of the interrupts and then return. The buffer will not be transmitted during the call to your function, instead the heavy lifting is deferred to a later stage.
We can further have a look at the source code, to get a proof from what I said (note I kept only the juicy parts).
Blocking
HAL_StatusTypeDef HAL_UART_Transmit(UART_HandleTypeDef *huart, uint8_t *pData, uint16_t Size, uint32_t Timeout)
{
uint16_t* tmp;
uint32_t tickstart = 0U;
// [ ... ]
huart->TxXferSize = Size;
huart->TxXferCount = Size;
while(huart->TxXferCount > 0U)
{
// [ ... ]
// This is were the actual HW regs are accessed, starting the transfer
huart->Instance->DR = (*pData++ & (uint8_t)0xFF);
}
}
// [ ... ]
return HAL_OK
}
Non Blocking
HAL_StatusTypeDef HAL_UART_Transmit_IT(UART_HandleTypeDef *huart, uint8_t *pData, uint16_t Size)
{
huart->pTxBuffPtr = pData;
huart->TxXferSize = Size;
huart->TxXferCount = Size;
/* Enable the UART Transmit data register empty Interrupt */
// This is the only part were HW regs are accessed. What is happening here??
SET_BIT(huart->Instance->CR1, USART_CR1_TXEIE);
return HAL_OK;
}
The _IT function only activates one interrupt, based also on the datasheet:
This means we will receive an interrupt whenever the TX buffer is free. Who is actually sending the data then?
With the help of the FAQs and reading the source code, we find that void HAL_UART_IRQHandler(UART_HandleTypeDef *huart) does something like this:
/* UART in mode Transmitter ------------------------------------------------*/
if(((isrflags & USART_SR_TXE) != RESET) && ((cr1its & USART_CR1_TXEIE) != RESET))
{
UART_Transmit_IT(huart);
return;
}
Which in turn calls the UART_Transmit_IT
static HAL_StatusTypeDef UART_Transmit_IT(UART_HandleTypeDef *huart)
{
uint16_t* tmp;
/* Check that a Tx process is ongoing */
if(huart->gState == HAL_UART_STATE_BUSY_TX)
{
huart->Instance->DR = (uint8_t)(*huart->pTxBuffPtr++ & (uint8_t)0x00FF);
if(--huart->TxXferCount == 0U)
{
/* Disable the UART Transmit Complete Interrupt */
CLEAR_BIT(huart->Instance->CR1, USART_CR1_TXEIE);
/* Enable the UART Transmit Complete Interrupt */
SET_BIT(huart->Instance->CR1, USART_CR1_TCIE);
}
return HAL_OK;
}
else
{
return HAL_BUSY;
}
}
This function transmits only one byte! It then decrements the counter for the transmission (remember, all the information was set into the uart handler) and if it reaches 0, finally the complete interrupt is called.
Interrupts
Note that StmCube does the peripheral initialization and interrupt linking for you, but if you program from scratch you need to remember to write and register UART_IRQ_Handler
You can find here the code navigator to review my snippets and investigate further.
I have code written by someone else (for a dsPIC33FJ128MC706A) - which initializes UART1 & PWMs and uses a busy wait in the U1Rx interrupt to get 14 bytes, and timer1 interrupts to update PWM registers if new data arrives (debugged - it enters the _U1RXInterrupt when data is sent)
I tried modifying it to use DMA instead of busy wait. I changed nothing in the initialization, but called the following function after initialization of UART:
unsigned char received_data1 [0x0f] __attribute__((space(dma)));
unsigned char received_data2 [0x0f] __attribute__((space(dma)));
void dma_init(void)
{
DMA0REQ = 0x000b; // IRQSEL = 0b0001011 (UART1RX))
DMA0PAD = (volatile unsigned int) &U1RXREG;
DMA0STA = __builtin_dmaoffset(received_data1);
DMA0STB = __builtin_dmaoffset(received_data2);
DMA0CNT = 0xe;//15 bytes in
DMA0CON = 0x0002; //continuous ping-pong + post-increment
IFS0bits.DMA0IF = 0;
IEC0bits.DMA0IE = 1;
DMA0CONbits.CHEN = 1;
}
This is based on example 22-10 in the FRM with a few slight changes (UART1 receiver instead of UART2). I can't seem to find other examples that don't use library functions (which I didn't even know existed up until I came across those examples).
(Also, to be consistent with the code I got, I put in _ISR after void instead of making interrupt an attribute, but that didn't change anything)
In the example, there was no interrupt for the UART1 receiver - but according to the FRM, it should be enabled. Made sense to me that I don't need to clear the interrupt flag myself (it would kind-of defeat the purpose of DMA if I needed to use the CPU for it).
And yet, when I send data, the breakpoint on DMA0Interrupt doesn't trigger, but the one on the default interrupt does, and I have PWMIF=1 and U1RXIF=1. I also tried commenting out the default ISR and adding a _U1ErrInterrupt even though examining the flags I didn't notice any error flags being raised, just the normal U1RXIF.
I don't understand why this would happen. I haven't changed the PWM code at all, and the PWM flag isn't raised in the original code when I place a breakpoint in the _U1RxInterrupt. I don't even understand how a DMA set-up could cause a PWM error.
The U1RXIF flag seems to be telling me the DMA didn't handle the incoming byte (I assume it's the DMA that clears the flag), which once again relates to the question "what did I do wrong in this DMA setup"
UART initialization code:
in a general initialization function (called by main())
TRISFbits.TRISF2 = 1; /* U1RX */
TRISFbits.TRISF3 = 0; /* U2TX */
also called by main:
void UART1_init_USB (void)
{
/* Fcy 7.3728 MHZ */
U1MODE = 0x8400; /* U1ATX Transmit status and control register */
U1STA = 0x2040; /* Receve status and control register Transmit disabled*/
U1BRG = 0x000f; /* Baund rate control register 115200 bps */
IPC2bits.U1RXIP = 3; /* Receiver Interrupt Priority bits */
IEC0bits.U1RXIE = 1; /* Enable RS232 interrupts */
IFS0bits.U1RXIF = 0;
}
(comments by original code author)
I have been using STM32 IDE which incorporates the CUBE MX.
Using the HAL code I am able to read on three pins using a separate ADC for each
pin.
I have started all the ADC's at the same time and then I poll for completion.
I am I correct in thinking these ADC reads should be practically simultaneous (i.e.
they all read in at a very similar time)?
Code fragment below.
Using a NUCLEO-STM32 F446RE btw.
MX_ADC1_Init();
MX_ADC2_Init();
MX_ADC3_Init();
MX_USART1_UART_Init();
/* USER CODE BEGIN 2 */
/* USER CODE END 2 */
/* Infinite loop */
/* USER CODE BEGIN WHILE */
while (1)
{
static int flip,sysclk=0,old_sysclk=0,adc1,adc2,adc3;//adc3_0,adc3_1,adc3_2, adc_pstat0,
int adc_pstat1, adc_pstat2, adc_pstat3;
flip ^= 1;
HAL_GPIO_WritePin(GPIOC,GPIO_PIN_0/*|GPIO_PIN_2|GPIO_PIN_6*/, flip);
HAL_ADC_Start(&hadc3);
HAL_ADC_Start(&hadc2);
HAL_ADC_Start(&hadc1);
adc_pstat1 = HAL_ADC_PollForConversion(&hadc1, 10);
adc_pstat3 = HAL_ADC_PollForConversion(&hadc3, 10); // should already be done!
adc_pstat2 = HAL_ADC_PollForConversion(&hadc2, 10); // should already be done!
adc3 = HAL_ADC_GetValue(&hadc3);
adc2 = HAL_ADC_GetValue(&hadc2);
adc1 = HAL_ADC_GetValue(&hadc1);
if (adc_pstat2 ||adc_pstat3)
asm("\t nop");
/* USER CODE END WHILE */
/* USER CODE BEGIN 3 */
sysclk = HAL_GetTick();
if ( (sysclk - 1000) > old_sysclk ){
//printf("nucleo F446 0x%X adc3_0 0x%X adc3_1 0x%X adc3_2 0x%X\n",sysclk,adc3_0,adc3_1,adc3_2);
printf("|->nucleo F446 sysclk=0x%X adc1=0x%X adc2=0x%X adc3=0x%X\n",sysclk,adc1,adc2,adc3);
old_sysclk = sysclk;
}
}
/* USER CODE END 3 */
}
Your code does not read it simultaneously as you do not start the ADCs at the sime moment.
You need to use the same external trigger for all of them or use ADCs in the double or tripple mode.
I found a way to do this easily. I set up a timer and used to to update a trigger event. The ADC's then triggered off this event (TIM8_TRGO).
Using this trigger I can get two or three ADCs to read simultaneously.
The Dual Simultaneous mode seems to support ADCs reading at the same time
I'm using hal can library for stm32L476vg mcu. I'm debugging my can transmission app and I can observe something apparently wrong in HAL_CAN_Transmit() sequence execution and its returned value, specially when it musts return HAL_TIMEOUT value.
Main code:
#include "main.h"
#include "Pm03_SystemConfig.h"
#include "App_Task_CAN.h"
uint8_t charBuffer[10]={0x00};
int main(void)
{
/* Reset of all peripherals, Initializes the Flash interface and the Systick. */
HAL_Init();
/* Configure the system clock */
Pm03_SystemClock_Config();
App_Task_CAN_reset();
App_Task_CAN_init();
charBuffer[0]=0xCA;
charBuffer[1]=0xFE;
while (1)
{
App_Task_CAN_sendData(&charBuffer[0]);
}
}
My TX higher level function implementation that calls hal_can transmit and init for can configuration in App_Task_CAN.c file:
uint8_t App_Task_CAN_sendData(uint8_t* cBuffer)
{
for (uint8_t index=0; index< DATABTXLONG; index ++)
{
HCAN_Struct.pTxMsg->Data[index]= cBuffer[index];
}
if (HAL_CAN_Transmit(&HCAN_Struct, TIMEOUT)!=HAL_OK)
{
TaskCan_Error_Handler();
}
}
void App_Task_CAN_init(void)
{
static CanTxMsgTypeDef TxMessage;
static CanRxMsgTypeDef RxMessage;
/*configuracion timing para obtener 500kb/s*/
HCAN_Struct.Instance = CAN1;
HCAN_Struct.pTxMsg = &TxMessage;
HCAN_Struct.pRxMsg = &RxMessage;
HCAN_Struct.Init.Prescaler = 1;
HCAN_Struct.Init.Mode = CAN_MODE_NORMAL;//values defined in different hal libraries
HCAN_Struct.Init.SJW = CAN_SJW_1TQ;
HCAN_Struct.Init.BS1 = CAN_BS1_6TQ;//segment point at 87.5%
HCAN_Struct.Init.BS2 = CAN_BS2_1TQ;
HCAN_Struct.Init.TTCM = DISABLE;
HCAN_Struct.Init.ABOM = DISABLE;
HCAN_Struct.Init.AWUM = DISABLE;
HCAN_Struct.Init.NART = DISABLE;
HCAN_Struct.Init.RFLM = DISABLE;//Fifo locked mode disabled
HCAN_Struct.Init.TXFP = DISABLE;//prioridad de tx por id (más bajo más prioridad)
if (HAL_CAN_Init(&HCAN_Struct) != HAL_OK)
{
TaskCan_Error_Handler();
}
//TX
HCAN_Struct.pTxMsg->StdId = 0x321;
HCAN_Struct.pTxMsg->ExtId = 0x01;//29 bits
HCAN_Struct.pTxMsg->IDE = CAN_ID_STD;//values defined in different hal libraries
HCAN_Struct.pTxMsg->RTR = CAN_RTR_DATA;//values defined in different hal libraries
HCAN_Struct.pTxMsg->DLC = DATABTXLONG;//1-9
}
some defines used above, declared in App_Task_CAN.h:
/* Timeout for can operations in bit time units */
#define TIMEOUT 100
/* param for config mesg frames */
#define DATABTXLONG 2
I was debugging and going step by step through all the hal transmit function sequence (concerned piece of code below) and I can see how, after first TXRQ ->
Part of hal_can_transmit function in stm32l4xx_hal_can.c file:
HAL_StatusTypeDef HAL_CAN_Transmit(CAN_HandleTypeDef* hcan, uint32_t Timeout)
{
...
/* Request transmission */
hcan->Instance->sTxMailBox[transmitmailbox].TIR |= CAN_TI0R_TXRQ;
...
/* Check End of transmission flag */
while(!(__HAL_CAN_TRANSMIT_STATUS(hcan, transmitmailbox)))
{
/* Check for the Timeout */
if(Timeout != HAL_MAX_DELAY)
{
if((Timeout == 0) || ((HAL_GetTick()-tickstart) > Timeout))
{
hcan->State = HAL_CAN_STATE_TIMEOUT;
/* Process unlocked */
__HAL_UNLOCK(hcan);//line in which thread breaks
return HAL_TIMEOUT;//ignored line during debug
}
}
}
...
}
(NOTE: This next piece of code belongs to hal library provided by ST)
-> once the thread passes through the above transmit call, after TXRQ line this happens:
the thread waits for end Tx flag and
after timeout value expires, the threads goes into timeout state line
it arrives until hal unlock() macro line
after this, it exits/breaks the execution and returns to the line where this function was called ignoring the next line "return HAL_TIMEOUT".
The thread is broken just before arriving to this line (red text line). It returns to my transmit call a HAL_OK value! I recieve HAL_OK value! I confirm this after mounting a switch case in order to see what value it was reciving instead of HAL_TIMEOUT.
It happens from the first time transmit is called. I don't know if it is normal behavior. Obviously it is a hal_can code fact and I can not do anything from code user to fix it.
Has someone else, who worked with hal can for stm32, faced this situation?
My Tx does not work and I was looking for the possible fail causes through debugging. Hence I have seen this. Maybe there is more than this code problem to solve. But I think my code is very simple to fail: I only call send data in a infinite loop (of course after can init). By debugging I can see how data is arriving to the mailboxes correctly, but flag of TXOk never sets.
So, maybe this hal_can strange behavior is part of the cause of my transmission fail.
It seems to be a third party bug. Has someone deal with same situation? Any suggestion about my user code? is there something to improve?
I'm trying to recreate a project of writing to an SD card (using FatFS) for a dsPIC33FJ128GP802 microcontroller.
Currently to collect the date from the SPI I have a do/while that loops 512 times and writes a dummy value to the SPI buffer, wait for the SPI flag, then read the SPI value, like so:
int c = 512;
do {
SPI1BUF = 0xFF;
while (!_SPIRBF);
*p++ = SPI1BUF;
} while (--c);
I'm trying to recreate this using the DMA intterupts but it's not working like I had hoped. I'm using one DMA channel, SPI is in 8 bit mode for the time being, so DMA is in byte mode, it's also in 'null write' mode, and continuous without ping pong. My buffers are only one member arrays and the DMA is matched.
DMA2CONbits.CHEN = 0; //Disable DMA
DMA2CONbits.SIZE = 1; //Receive bytes (8 bits)
DMA2CONbits.DIR = 0; //Receive from SPI to DMA
DMA2CONbits.HALF = 0; //Receive full blocks
DMA2CONbits.NULLW = 1; //null write mode on
DMA2CONbits.AMODE = 0; //Register indirect with post-increment
DMA2CONbits.MODE = 0; //continuous mode without ping-pong
DMA2REQbits.IRQSEL = 10; //Transfer done (SPI)
DMA2STA = __builtin_dmaoffset(SPIBuffA); //receive buffer
DMA2PAD = (volatile unsigned int) &SPI1BUF;
DMA2CNT = 0; //transfer count = 1
IFS1bits.DMA2IF = 0; //Clear DMA interrupt
IEC1bits.DMA2IE = 1; //Enable DMA interrupt
From what I understand from the null write mode, the DMA will write a null value every time a read is performed. However, the DMA wont start until an initial write is performed by the CPU, so I've used the manual/force method to start the DMA.
DMA1CONbits.CHEN = 1; //Enable DMA
DMA1REQbits.FORCE = 1; //Manual write
The interrupt will now start, and runs without error. However the code later shows that the collection was incorrect.
My interrupt is simple in that all I'm doing is placing the collected data (which I assume is placed in my DMAs buffer as allocated above) into a pointer which is used throughout my program.
void __attribute__((interrupt, no_auto_psv)) _DMA2Interrupt(void) {
if (RxDmaBuffer == 513) {
DMA2CONbits.CHEN = 0;
rxFlag = 1;
} else {
buffer[RxDmaBuffer] = SPI1BUF;
RxDmaBuffer++;
}
IFS1bits.DMA2IF = 0; // Clear the DMA0 Interrupt Flag
}
When the interrupt has run 512 times, I stop the DMA and throw a flag.
What am I missing? How is this not the same as the non-DMA method? Is it perhaps the lack of the while loop which waits for the completion of the SPI transmission (while (!_SPIRBF);). Unfortunately with the null write mode automatically sending and receiving the SPI data I can't manually put any sort of wait in.
I've also tried using two DMA channels, one to write and one to read, but this also didn't work (plus I need that channel later for when I come to proper writing to the SD card).
Any help would be great!