Forum Replies Created
-
Posts
-
Okay then, after further investigation your VCP_write() must still have a bug. I wrote an alternate function with code
stolen frominspired by Atmel SAM3X USB core lib and it works now. Here is my signal data looking good and all:
And here is the function which should handle transmitting >64 bytes over USB FS correctly:
int VCP_AltWrite(const void *pBuffer, int len) { uint32_t n; int r = len; uint8_t* data = (uint8_t*)pBuffer; USBD_CDC_HandleTypeDef *pCDC = (USBD_CDC_HandleTypeDef *)USBD_Device.pClassData; while (pCDC->TxState) {} //Wait for previous transfer while (len) { n = kMaxOutPacketSize; if (n > len) n = len; len -= n; USBD_CDC_SetTxBuffer(&USBD_Device, data, n); if (USBD_CDC_TransmitPacket(&USBD_Device) != USBD_OK) return 0; while (pCDC->TxState) {} //Wait until transfer is done data += n; } return r; }Note also the long string mentioned in my previous post prints out correctly using this function. Now, where do I pick up my paycheck…? 😉
Thanks, this does not work for me. With your bug fixed version I am still seeing noise on the data and with the corrected, reduced FS buffer limit it is now worse than before. Here is how the signal data looks — and should look — with my no-size-check version:
And here is the equivalent output via VCP_write():
To test further I disabled all irrelevant peripherals in my program to avoid interference and printed out this long string once every 5 seconds in a loop:
“ABCDEFGHIJKLMNOPQRSTUVWXYZ_0123456789_abcdefghijklmnopqrstuvwxyz_9876543210:::::\r\n”
In a terminal window (termite or SmartTTY) a single VCP_write() call outputs the below. Note that the string is not transmitted to the end and also clipped from start, one character at the time:
ABCDEFGHIJKLMNOPQRSTUVWXYZ_0123456789_abcdefghijklmnopqrstuvwxyzBCDEFGHIJKLMNOPQRSTUVWXYZ_0123456789_abcdefghijklmnopqrstuvwxyz_CDEFGHIJKLMNOPQRSTUVWXYZ_0123456789_abcdefghijklmnopqrstuvwxyz_9DEFGHIJKLMNOPQRSTUVWXYZ_0123456789_abcdefghijklmnopqrstuvwxyz_98EFGHIJKLMNOPQRSTUVWXYZ_0123456789_abcdefghijklmnopqrstuvwxyz_987FGHIJKLMNOPQRSTUVWXYZ_0123456789_abcdefghijklmnopqrstuvwxyz_9876GHIJKLMNOPQRSTUVWXYZ_0123456789_abcdefghijklmnopqrstuvwxyz_98765HIJKLMNOPQRSTUVWXYZ_0123456789_abcdefghijklmnopqrstuvwxyz_987654IJKLMNOPQRSTUVWXYZ_0123456789_abcdefghijklmnopqrstuvwxyz_9876543JKLMNOPQRSTUVWXYZ_0123456789_abcdefghijklmnopqrstuvwxyz_98765432KLMNOPQRSTUVWXYZ_0123456789_abcdefghijklmnopqrstuvwxyz_987654321LMNOPQRSTUVWXYZ_0123456789_abcdefghijklmnopqrstuvwxyz_9876543210MNOPQRSTUVWXYZ_0123456789_abcdefghijklmnopqrstuvwxyz_9876543210:NOPQRSTUVWXYZ_0123456789_abcdefghijklmnopqrstuvwxyz_9876543210::OPQRSTUVWXYZ_0123456789_abcdefghijklmnopqrstuvwxyz_9876543210:::PQRSTUVWXYZ_0123456789_abcdefghijklmnopqrstuvwxyz_9876543210::::QRSTUVWXYZ_0123456789_abcdefghijklmnopqrstuvwxyz_9876543210:::::RSTUVWXYZ_0123456789_abcdefghijklmnopqrstuvwxyz_9876543210::::: STUVWXYZ_0123456789_abcdefghijklmnopqrstuvwxyz_9876543210::::: TUVWXYZ_0123456789_abcdefghijklmnopqrstuvwxyz_9876543210::::: UVWXYZ_0123456789_abcdefghijklmnopqrstuvwxyz_9876543210::::: VWXYZ_0123456789_abcdefghijklmnopqrstuvwxyz_9876543210::::: WXYZ_0123456789_abcdefghijklmnopqrstuvwxyz_9876543210::::: XYZ_0123456789_abcdefghijklmnopqrstuvwxyz_9876543210::::: YZ_0123456789_abcdefghijklmnopqrstuvwxyz_9876543210::::: Z_0123456789_abcdefghijklmnopqrstuvwxyz_9876543210::::: _0123456789_abcdefghijklmnopqrstuvwxyz_9876543210::::: 0123456789_abcdefghijklmnopqrstuvwxyz_9876543210::::: 123456789_abcdefghijklmnopqrstuvwxyz_9876543210::::: 23456789_abcdefghijklmnopqrstuvwxyz_9876543210::::: 3456789_abcdefghijklmnopqrstuvwxyz_9876543210::::: 456789_abcdefghijklmnopqrstuvwxyz_9876543210::::: 56789_abcdefghijklmnopqrstuvwxyz_9876543210::::: 6789_abcdefghijklmnopqrstuvwxyz_9876543210::::: 789_abcdefghijklmnopqrstuvwxyz_9876543210::::: 89_abcdefghijklmnopqrstuvwxyz_9876543210::::: 9_abcdefghijklmnopqrstuvwxyz_9876543210::::: _abcdefghijklmnopqrstuvwxyz_9876543210::::: abcdefghijklmnopqrstuvwxyz_9876543210::::: bcdefghijklmnopqrstuvwxyz_9876543210::::: cdefghijklmnopqrstuvwxyz_9876543210::::: defghijklmnopqrstuvwxyz_9876543210::::: efghijklmnopqrstuvwxyz_9876543210::::: fghijklmnopqrstuvwxyz_9876543210::::: ghijklmnopqrstuvwxyz_9876543210::::: hijklmnopqrstuvwxyz_9876543210::::: ijklmnopqrstuvwxyz_9876543210::::: jklmnopqrstuvwxyz_9876543210::::: klmnopqrstuvwxyz_9876543210::::: lmnopqrstuvwxyz_9876543210::::: mnopqrstuvwxyz_9876543210::::: nopqrstuvwxyz_9876543210::::: opqrstuvwxyz_9876543210::::: pqrstuvwxyz_9876543210::::: qrstuvwxyz_9876543210::::: rstuvwxyz_9876543210::::: stuvwxyz_9876543210::::: tuvwxyz_9876543210::::: uvwxyz_9876543210::::: vwxyz_9876543210::::: wxyz_9876543210::::: xyz_9876543210::::: yz_9876543210::::: z_9876543210::::: _9876543210::::: 9876543210::::: 876543210::::: 76543210::::: 6543210::::: 543210::::: 43210::::: 3210::::: 210::::: 10::::: 0::::: ::::: :::: ::: :: :
I’ll keep investigating this during the remainder of the day to see if I can find the issue.
Hi,
I think your points 2 and 3 are my problem, both object files contain only a .data section with different file offsets.
I have given up on trying to make this bootloader (made using another environment) work and will instead roll my own from scratch and in VisualGDB later.
Off to buy an embedded license, the evaluation period and support on this forum has convinced me that this is the right tool invest in.
O/T feature request: I’d personally love it if the online user documentation was in searchable/indexed format, (e.g. http://infocenter.arm.com). An added bonus would be a PDF user’s manual, to have something to read on the go. There is so much useful information available on the website but it is not always easy to find the relevant pages. I think this alongside projects with source code attached with each tutorial would make transitioning and/or learning this environment a whole lot easier.
Hi,
Thanks, that is very neat, however, I encountered a couple of problems. First, I cannot find the type Properties->Embedded Resource, did you mean Embedded Binary which has a Section option?
Second, my bootloader consists of 2 parts, a boot reset vector that goes to the top of Flash memory and bootloader code which is placed at the bottom. When I first add the bootloader reset vector all is fine, e.g. linker script:
MEMORY { FLASH (RX) : ORIGIN = 0x08000000, LENGTH = 0xE0000 /* 1M */ BOOTLDR (RX) : ORIGIN = 0x080E0000, LENGTH = 0x20000 SRAM (RWX) : ORIGIN = 0x20000000, LENGTH = 128K CCMRAM (RWX) : ORIGIN = 0x10000000, LENGTH = 64K } _estack = 0x20020000; SECTIONS { .bootrstv : { . = ALIGN(4); KEEP(*(.bootrstv)) } > FLASH .isr_vector : { . = ALIGN(4); KEEP(*(.isr_vector)) . = ALIGN(4); } > FLASH ...This produces a correctly looking memory map:
0x20020000 _estack = 0x20020000 .bootrstv 0x08000000 0x14 0x08000000 . = ALIGN (0x4) *(.bootrstv) .bootrstv 0x08000000 0x14 VisualGDB/Debug/bootrstv.o 0x08000000 _binary_bootrstv_bin_start 0x08000014 _binary_bootrstv_bin_end .isr_vector 0x08000014 0x188 0x08000014 . = ALIGN (0x4) *(.isr_vector) .isr_vector 0x08000014 0x188 VisualGDB/Debug/startup_stm32f407xx.o 0x08000014 g_pfnVectors 0x0800019c . = ALIGN (0x4)
Then, as soon as I also add the bootloader.bin file to the project, without doing anything else, the .bootrstv object file is not included in the build and entire section is set to zero length. So after inclusion of a second .bin file the memory map turns out like this:
0x20020000 _estack = 0x20020000 .bootrstv 0x08000000 0x0 0x08000000 . = ALIGN (0x4) *(.bootrstv) .isr_vector 0x08000000 0x188 0x08000000 . = ALIGN (0x4) *(.isr_vector) .isr_vector 0x08000000 0x188 VisualGDB/Debug/startup_stm32f407xx.o 0x08000000 g_pfnVectors 0x08000188 . = ALIGN (0x4)
There is a little bit more to this story. I started from scratch with a new LEDBlink template, added code from the tutorial, and could not reproduce the build errors. Long story short, there is nothing wrong with the tutorial.
In the process I found what my problem was all along. The ‘#ifdef __cplusplus extern “C” #endif’ at the beginning actually belongs to the SysTick_Handler. I got confused and thought the #ifdef was for the entire source file because there are no curly braces that wraps this specific function.
So, when moving all global variable declarations to the top of the source file, which I normally do to have them collected in one place, I placed them between the #ifdef segment and SysTick_Handler. This generated an undefined reference error for the first variable declared after the #ifdef segment due to it now being declared extern “C”.
Figured it out eventually, yay!
DEBUG_DEFAULT_INTERRUPT_HANDLERS goes into Project properties->Makefile settings->Preprocessor macros
Building+running with this macro pointed me to a missing SysTick_Handler() interrupt. I had this function already in my code but it was not explicitly declared as extern “C”.
When adding ADC interrupt handler and callback (step 13 in tutorial), which are wrapped in an extern “C” declaration I got several build errors. To get rid of these I had to remove the “#ifdef __cplusplus/extern “C”/#endif” section at the beginning of the main source file. This definition is put there automatically when creating a LEDBlink sample project, which the ADC tutorial is built upon. The example code with added ADC interrupt handlers will not compile unless ‘#ifdef…’ is removed but in doing so the SysTick_Handler() is no longer valid unless explicitly declared as ‘extern “C”. I think this should be mentioned somewhere to avoid confusion.
Thanks, yes it is stuck looping in Default_Handler(). I’m really not sure what I am missing, checked my code for the Nth time against the example and I can’t see anything that differs.
In the default handler there is a comment;
//If you get stuck here, your code is missing a handler for some interrupt.
//Define a ‘DEBUG_DEFAULT_INTERRUPT_HANDLERS’ macro via VisualGDB Project Properties and rebuild your project.
//This will pinpoint a specific missing vector.Where exactly in properties should I define this?
