Problem stm32f101x UART4

[tiaandpz]

Posted on November 05, 2013 at 14:57

The original post was too long to process during our migration. Please click on the attachment to read the original post.

[Tesla DeLorean]

Posted on November 05, 2013 at 15:23

Couple of tips, there is a ''Format Code Block'' (Paintbrush [< >]) icon.

With library version v3.5.0 should you be using UART4_IRQn ? Code to enable the IRQ is absent.

Does the part have a UART4? Do you enable the GPIOC clock someplace?

[tiaandpz]

Posted on November 06, 2013 at 09:43

With library version v3.5.0 should you be using UART4_IRQn ?

The project uses firmware library 2.0.3 which includes stm32f10x_nvic.c (This file refers to UART 4.) Before using UART4, UART3 was remapped to pin PC10 and PC11 ( with start up file STM32F10x.s, included with Keil uVision 4.22) That startup file does not list UART4, therefore I included the current start up file. ----------------------------------------------------------------------------------------------- When I included ''startup_stm32f10x_hd.s'' the code gets stuck at the last reference of ''DMA2_Channel4_5_IRQHandler''. The current start up file mentioned above has the following changes amde to it, compared to ''startup_stm32f10x_hd.s'': Take out:

IMPORT SystemInit
LDR R0, =SystemInit
BLX R0

Changed these names:

DMA1_Channel1_IRQHandler
DMA1_Channel2_IRQHandler
DMA1_Channel3_IRQHandler
DMA1_Channel4_IRQHandler
DMA1_Channel5_IRQHandler
DMA1_Channel6_IRQHandler
DMA1_Channel7_IRQHandler
ADC1_2_IRQHandler
USB_HP_CAN1_TX_IRQHandler
USB_LP_CAN1_RX0_IRQHandler
CAN1_RX1_IRQHandler
CAN1_SCE_IRQHandler

to:

DMAChannel1_IRQHandler
DMAChannel2_IRQHandler
DMAChannel3_IRQHandler
DMAChannel4_IRQHandler
DMAChannel5_IRQHandler
DMAChannel6_IRQHandler
DMAChannel7_IRQHandler
ADC_IRQHandler
USB_HP_CAN_TX_IRQHandler
USB_LP_CAN_RX0_IRQHandler
CAN_RX1_IRQHandler
CAN_SCE_IRQHandler

----------------------------------------------------------------------------------------------- Code to enable the IRQ is absent. Sorry should have included it. Here it is

void IR_ProcessRX() {
// This function processes data that comes in. It looks for data in RXTmpBuffer
// and copies it over to RXBuffer if it exists. Then it looks to see if the data
// is completer and processes it if it is.
// If there is no incoming data, this function exists almost immediately.
// Doing this saves significant processing time by not rechecking the same
// (incomplete) message multiple times.
s16 CRLFPos;
u16 i;
u16 pos, epos;
u8 Valid, tmp;
u8 BCC;
u32 address, length;
NVIC_InitTypeDef NVIC_InitStructure;
u8 bytescopied;
u8 processedcrlf = FALSE;
bytescopied = 0;
// Process RX buffer, so must turn off interrupt
NVIC_InitStructure.NVIC_IRQChannel = USART_IR_IRQChannel;
NVIC_InitStructure.NVIC_IRQChannelPreemptionPriority = 1;
NVIC_InitStructure.NVIC_IRQChannelSubPriority = 0;
NVIC_InitStructure.NVIC_IRQChannelCmd = DISABLE;
NVIC_Init(&NVIC_InitStructure);
// This is the only place outside of the interrupt where RXTmpBuffer (and
// RXTmpBufferHead, RXTmpBufferTail, RXTmpBufferError) are accessed.
if (RXTmpBufferError) {
// There was a reception error, such as buffer overrun, framing error, or something
// similarly catastrophic, so trash the reception buffer completely!
RXBufferLen = 0;
RXTmpBufferLen = 0;
RXTmpBufferError = 0; // Will allow data to start being received again
} else {
if (RXDBG1 < 
RXTmpBufferLen
) 
RXDBG1
= 
RXTmpBufferLen
;
// Copy any data from the temporary RXTmpBuffer to the full size RXBuffer
if (RXBufferLength > (RXBufferLen+RXTmpBufferLen)) {
memcpy(RXBuffer+RXBufferLen, RXTmpBuffer, RXTmpBufferLen);
RXBufferLen += RXTmpBufferLen;
bytescopied = RXTmpBufferLen;
RXTmpBufferLen = 0;
} else {
// No more space in the reception buffer, so trash everything
RXTmpBufferLen = 0;
RXBufferLen = 0;
bytescopied = 0;
}
}
// We've finished with the buffer, so enable the interrupt again...
NVIC_InitStructure.NVIC_IRQChannelCmd = ENABLE;
NVIC_Init(&NVIC_InitStructure);
if (bytescopied > 0) {
// Data was copied, so it makes sense to proceed...
//..........

Does the part have a UART4? Do you enable the GPIOC clock someplace? Yes it does have a UART4. GPIOC clock is enabled in another part of the code. Greetings

[Tesla DeLorean]

Posted on November 06, 2013 at 13:46

The project uses firmware library 2.0.3 which includes stm32f10x_nvic.c (This file refers to UART 4.)

Don't mix and match the library code, ignore what Keil comes with, and use the 3.5.0 library from ST, make sure to set the correct pre-processor defines within the project to match the chip class being used, and the include search paths to those of the ST library. Review the Template project.

[tiaandpz]

Posted on November 06, 2013 at 16:16

I do not see any stm32f10x_nvic.c (am I missing it) in the library version 3.5.0.

Is their a big difference between library 2.0.3 and 3.5.0.

It is an existing project and I want to make as few changes as possible.

Do you think the problem might be that the start up file and the library files does not match?

Could I use start up file version 3.4.0 with library version 2.0.3? I guess this mixing. These files are supplied with Keil vesion 4.22?

[Tesla DeLorean]

Posted on November 06, 2013 at 18:24

Yes, things are somewhat different as they migrated to the CMSIS library model, the NVIC stuff for example now exists within the generic Cortex-M3 support provided by the CMSIS code, and STM32F10x_StdPeriph_Lib_V3.5.0\Libraries\STM32F10x_StdPeriph_Driver\src\misc.c

So things related to NVIC, Core, reset, etc.

Porting is not that hard, I've ported 2.x projects to 3.x, and also F1 projects to F2, they took perhaps an afternoon of focused effort, on a project of reasonable size, and clean abstraction. YMMV

Your alternative is to back-port the features/chips supported by 3.5.0 or 3.4.0 into 2.x, but honestly I think that's harder to maintain and document.

[tiaandpz]

Posted on November 07, 2013 at 07:20

Hi Clive 

There does not seem to be that much of a difference between start up file provide by keil (that was previously used in this project) and the one from ST (v3.5.0), except for the extra IRQ handlers.

If I port my code to use ST's library version 3.5.0, would that solve my problem (UART4 not working) ?

Greetings