I was having trouble on the STM32L462xx with setting the device up for flashing over USB without having access to the BOOT0 pin. Going off of the tutorial on the ST site didn't seem to accomplish the task. Has anyone successfully set the STM32L4 into bootloader mode from software?
https://stm32f4-discovery.net/2017/04/tutorial-jump-system-memory-software-stm32/
I was able to set the device into a mode which it can be programmed with STM32Cube Programmer or the DFU-util program using the following code. This is partly a signal boost for this programmers solution which went against the ST tutorial on their site saying how to put jump the device memory to bootloader for USB programming
https://github.com/markusgritsch/SilF4ware/blob/94bb679119a0b9879fedc62a5e22f40623433242/SilF4ware/drv_reset.c
void jump_to_bootloader(void)
{
__enable_irq();
HAL_RCC_DeInit();
HAL_DeInit();
SysTick->CTRL = SysTick->LOAD = SysTick->VAL = 0;
__HAL_SYSCFG_REMAPMEMORY_SYSTEMFLASH();
const uint32_t p = (*((uint32_t *) 0x1FFF0000));
__set_MSP( p );
void (*SysMemBootJump)(void);
SysMemBootJump = (void (*)(void)) (*((uint32_t *) 0x1FFF0004));
SysMemBootJump();
while( 1 ) {}
}
Related
I have tried many different drivers and cannot successfully send data from the uC to the computer over USBSerial. I am trying the mbed-official USBSerial driver but have had the same results with the KL25Z fork and the ST micro fork as well as mbed OS2 an OS5. I am able to receive bytes freely from the computer to the uC but I cannot send data the other direction.
I have tried 3 different methods to send data to the computer: _putc(), writeBlock(), and printf(). For all three methods, the first byte is sent back to the computer successfully but then the device gets stuck in an endless while loop on line 863 in USBDevice.cpp. This is the 'Wait for completion' portion of the USBDevice::write() function.
I do not feel that I have enough knowledge about USB interfaces to properly debug this driver.
I have published my test program here.
#include "mbed.h"
#include "USBSerial.h"
//Virtual serial port over USB
USBSerial serial;
DigitalOut thisLED(LED1);
char temp[1];
void receiveSerial()
{
while (serial.readable())
{
temp[0] = serial._getc();
serial._putc(temp[0]);
//serial.writeBlock((uint8_t *) temp,1);
//serial.printf(temp);
}
}
int main(void) {
serial.attach(&receiveSerial);
while(1)
{
thisLED = !thisLED;
wait(1);
}
}
I am working on a NUCLEO-L476RG board, trying to start the bootloader from my firmware code but its not working for me. here is the code that i am trying to execute :
#include "stm32l4xx.h"
#include "stm32l4xx_nucleo.h"
#include "core_cm4.h"
#include "stm32l4xx_hal_uart.h"
GPIO_InitTypeDef GPIO_InitStructure;
UART_HandleTypeDef UartHandle;
UART_InitTypeDef UART_InitStructre;
void BootLoaderInit(uint32_t BootLoaderStatus){
void (*SysMemBootJump)(void) = (void (*)(void)) (*((uint32_t *) 0x1FFF0004));
if(BootLoaderStatus == 1) {
HAL_DeInit(); // shut down running tasks
// Reset the SysTick Timer
SysTick->CTRL = 0;
SysTick->LOAD = 0;
SysTick->VAL =0;
__set_PRIMASK(1); // Disable interrupts
__set_MSP((uint32_t*) 0x20001000);
SysMemBootJump();
}
}
int main(void)
{
HAL_Init();
__GPIOC_CLK_ENABLE();
GPIO_InitStructure.Pin = GPIO_PIN_13;
GPIO_InitStructure.Mode = GPIO_MODE_INPUT;
GPIO_InitStructure.Pull = GPIO_PULLUP;
GPIO_InitStructure.Speed = GPIO_SPEED_FAST;
HAL_GPIO_Init(GPIOC, &GPIO_InitStructure);
while (1) {
if (HAL_GPIO_ReadPin(GPIOC, GPIO_PIN_13)) {
BootLoaderInit(1);
}
}
return 0;
}
What i hope to get after the execution of the firmware is that i can connect to the board with a UART and send commands/get responses from the bootloader. the commands i am trying to use come from here: USART protocol used in the STM32 bootloader.
I don't see and response from the board after connecting with the UART.
Here are some ideas taken from the answers to this question.
HAL_RCC_DeInit();
This is apparently needed to put the clocks back into the state after reset, as the bootloader expects them to be.
__HAL_REMAPMEMORY_SYSTEMFLASH();
Maps the system bootloader to address 0x00000000
__ASM volatile ("movs r3, #0\nldr r3, [r3, #0]\nMSR msp, r3\n" : : : "r3", "sp");
Set the stack pointer from bootloader ROM. Where does your 0x20001000 come from? If it's an arbitrary value, then the stack can clobber the bootloader's variables.
Then there is this alternate solution:
When I want to jump to the bootloader, I write a byte in one of the
backup register and then issue a soft-reset. Then, when the processor
will restart, at the very beginning of the program, it will read this
register.
Note that you need LSI or LSE clock for accessing the backup registers.
Try to avoid using __set_MSP(), as current implementation of this function does NOT allow you to change MSP if it is also the stack pointer which you currently use (and you most likely are). The reason is that this function marks "sp" as clobbered register, so it will be saved before and restored afterwards.
See here - STM32L073RZ (rev Z) IAP jump to bootloader (system memory)
Find your bootloader start address from the reference manual.
Then use the following code.
Make sure you have cleaned and disabled the interrupts before do so.
/* Jump to different address */
JumpAddress = *(__IO uint32_t*) (BootloaderAddress + 4);
Jump_To_Application = (pFunction) JumpAddress;
/* Initialize user application's Stack Pointer */
__set_MSP(*(__IO uint32_t*) ApplicationAddress);
Jump_To_Application();
Please have a look at Official STM32 AppNote as well.
I've been trying to set up some basic usb comunication with a usb mouse using my stm32f4 discvery. there are no usb examples for my board so I went in to look at other boards.
stm's Cube library thingy promissed easy development and all, so I generated a project with cube inlcuding USB_OTG_FS in host only mode and four IO pins for LED's.
I had a look in the files and it seemed like reading mouse buttons would be fairly trivial, but I can't make it work.
if I run
devtype = USBH_HID_GetDeviceType(&hUsbHostFS);
it detects the device correctly.
USBH_HID_MouseInit(&hUsbHostFS)
returns USBH_OK,
but no matter what I try
mouse=USBH_HID_GetMouseInfo(&hUsbHostFS);
is always NULL
"USBH_HID_MouseInit" is never mentioned in the documentation(DM00105256.pdf)
also, only the RTOS examples use them. Reading the usb host standalone example, it would seem that to comunicate with a mouse would be as simple as runing GetDeviceType, and poll GetMouseInfo, but I can't get it to work.
this is all the code I added, it's executed in the main while
if(Appli_state == APPLICATION_READY){
switch(state)
{
case 0:
devtype = USBH_HID_GetDeviceType(&hUsbHostFS);
if(devtype == HID_MOUSE){
HAL_GPIO_WritePin(GPIOD,GPIO_PIN_14,1);
HAL_GPIO_WritePin(GPIOD,GPIO_PIN_12,0);
state=1;
}
else if(devtype == HID_KEYBOARD){
HAL_GPIO_WritePin(GPIOD,GPIO_PIN_14,0);
HAL_GPIO_WritePin(GPIOD,GPIO_PIN_12,1);
state=2;
}
else{
HAL_GPIO_WritePin(GPIOD,GPIO_PIN_14,0);
HAL_GPIO_WritePin(GPIOD,GPIO_PIN_12,0);
}
break;
case 1:
if(USBH_HID_MouseInit(&hUsbHostFS)==0){
HAL_GPIO_WritePin(GPIOD,GPIO_PIN_15,1);
state=3;
}
else {
HAL_GPIO_WritePin(GPIOD,GPIO_PIN_15,0);
state=0;
}
break;
case 3:
mouse=USBH_HID_GetMouseInfo(&hUsbHostFS);
if(mouse != NULL)HAL_GPIO_WritePin(GPIOD,GPIO_PIN_13,1);
else HAL_GPIO_WritePin(GPIOD,GPIO_PIN_13,0);
break;
default:
break;
}
}
if(Appli_state != APPLICATION_READY) state=0;
rest of the code is unchanged. like I said before it detects the connection and if it's a mouse, keyboard or unknown device just fine. I just can't get it to communicate
The Cube is buggy, coded in a strange way, and not well documented.
Depending on the actual board you have, you must make sure the clocks are setup correctly (in system_stm32f4.c)
With the stm32f407-based version (http://www.st.com/en/evaluation-tools/stm32f4discovery.html) you should use these settings:
HSE = 8000000
PLL_M = 8
PLL_Q = 7
PLL_N = 336
PLL_P = 4
The USB OTG FS requires a 48MHz clock. Here are the equations:
USB OTG FS, SDIO and RNG Clock = PLL_VCO / PLLQ
PLL_VCO = (HSE_VALUE / PLL_M) * PLL_N
I have a board that is connected to USB on a STM32F107 with the following pins
USB_OTG_VBUS : PA9
USBDM : PA11
USBDP : PA12
I have a project that needs to use both Virtual Com Port and USB Mass Storage. It needs to re-enumerate the USB then do a software reset to enable the different USB class.
I have tried various different things to get it to re-enumerate but so far have been unable to, the only way to re-enumerate is to unplug usb cable.
These are some of the functions i have tried with no success
USB_OTG_DisableGlobalInt(&USB_OTG_dev);
USB_OTG_WRITE_REG32(&USB_OTG_dev.regs.GREGS->GINTSTS, 0xBFFFFFFF);
USB_OTG_CoreReset(&USB_OTG_dev);
USBD_DeInit(&USB_OTG_dev);
DCD_DevDisconnect(&USB_OTG_dev);
NVIC_SystemReset();
Would anyone have any ideas on how to get the USB to re-enumerate when it is configured with only these 3 pins for the STM32F107?
If you're using a demo board, it has the functionality to disconnect the USB through a microcontroller pin. If you're not using a demo board, you need to come up with that ability yourself, by disconnecting the pull-up resistor on the USB_DM/USB_DP line...
Before initializing USB peripheral, configure D+ pin (USBP) as GPIO output push-pull and set low (0V) for 5ms. Then initiate standard USB configuration including GPIO. After this procedure USB host recognizes new device and starts enumeration.
GPIO_InitTypeDef GPIO_InitStructure;
GPIO_InitStructure.GPIO_Pin = GPIO_Pin_12;
GPIO_InitStructure.GPIO_Mode = GPIO_Mode_Out_PP;
GPIO_InitStructure.GPIO_Speed = GPIO_Speed_50MHz;
GPIO_Init(GPIOA, &GPIO_InitStructure);
GPIO_ResetBits(GPIOA, GPIO_Pin_12);
delay_ms(5);
//call your USB Init here
Worked for me.
source
Had a similar problem. Try this:
USB_OTG_dev.regs.GREGS->GCCFG = 0;
Wait a bit and then init the USB again.
I used the answer from #viteo and tweaked it a little as I had some compile errors. This code works on the Blue Pill development board (STM32F103C8), which includes a 1.5k pullup resistor on the PA12 (USB_DP) line. Therefore, this code forces the USB_DP line low for a short time, which is like the USB cable has been unplugged and reconnected, thereby forcing the host to re-enumerate the bus when the USB is subsequently configured.
Edit USB_DEVICE/App/usb_device.c and add the code inside the USB_DEVICE_Init_PreTreatment block
void MX_USB_DEVICE_Init(void)
{
/* USER CODE BEGIN USB_DEVICE_Init_PreTreatment */
GPIO_InitTypeDef GPIO_InitStruct = {0};
GPIO_InitStruct.Pin = GPIO_PIN_12;
GPIO_InitStruct.Mode = GPIO_MODE_OUTPUT_PP;
GPIO_InitStruct.Pull = GPIO_PULLDOWN;
GPIO_InitStruct.Speed = GPIO_SPEED_HIGH;
HAL_GPIO_Init(GPIOA, &GPIO_InitStruct);
HAL_GPIO_WritePin(GPIOA, GPIO_PIN_12, GPIO_PIN_RESET);
HAL_Delay(100);
/* USER CODE END USB_DEVICE_Init_PreTreatment */
I'm trying to communicate with the Enttec USB DMX Pro. Mainly receiving DMX.
They released a Visual C++ version here, but I'm a little stumped on what to do to convert to Obj-c. Enttec writes, "Talk to the PRO using FTDI library for Mac, and refer to D2XX programming guide to open and talk to the device." Any example apps for Objective-C out there? Is there an easy way to communicate with the Enttec DMX USB Pro?
I've done a significant amount of work with the FTDI chips on the Mac, so I can provide a little insight here. I've used the single-channel and dual-channel variants of their USB-serial converters, and they all behave the same way.
FTDI has both their Virtual COM Port drivers, which create a serial COM port on your system representing the serial connection attached to their chip, and their D2XX direct communication libraries. You're going to want to work with the latter, which can be downloaded from their site for various platforms.
The D2XX libraries for the Mac come in a standalone .dylib (the latest being libftd2xx.1.2.2.dylib) or a new static library they started shipping recently. Included in that package will be the appropriate header files you need (ftd2xx.h and WinTypes.h) as well.
In your Xcode project, add the .dylib as a framework to be linked in, and add the ftd2xx.h, WinTypes.h, and ftd2xx.cfg files to your project. In your Copy Bundled Frameworks build phase, make sure that libftd2xx.1.2.2.dylib and ftd2xx.cfg are present in that phase. You may also need to adjust the relative path that this library expects, in order for it to function within your app bundle, so you may need to run the following command against it at the command line:
install_name_tool -id #executable_path/../Frameworks/libftd2xx.1.2.2.dylib libftd2xx.1.2.2.dylib
Once your project is all properly configured, you'll want to import the FTDI headers:
#import "ftd2xx.h"
and start to connect to your serial devices. The example you link to in your question has a downloadable C++ sample that shows how they communicate to their device. You can bring across almost all of the C code used there and place it within your Objective-C application. They just look to be using the standard FTDI D2XX commands, which are described in detail within the downloadable D2XX Programmer's Guide.
This is some code that I've lifted from one of my applications, used to connect to one of these devices:
DWORD numDevs = 0;
// Grab the number of attached devices
ftdiPortStatus = FT_ListDevices(&numDevs, NULL, FT_LIST_NUMBER_ONLY);
if (ftdiPortStatus != FT_OK)
{
NSLog(#"Electronics error: Unable to list devices");
return;
}
// Find the device number of the electronics
for (int currentDevice = 0; currentDevice < numDevs; currentDevice++)
{
char Buffer[64];
ftdiPortStatus = FT_ListDevices((PVOID)currentDevice,Buffer,FT_LIST_BY_INDEX|FT_OPEN_BY_DESCRIPTION);
NSString *portDescription = [NSString stringWithCString:Buffer encoding:NSASCIIStringEncoding];
if ( ([portDescription isEqualToString:#"FT232R USB UART"]) && (usbRelayPointer != NULL))
{
// Open the communication with the USB device
ftdiPortStatus = FT_OpenEx("FT232R USB UART",FT_OPEN_BY_DESCRIPTION,usbRelayPointer);
if (ftdiPortStatus != FT_OK)
{
NSLog(#"Electronics error: Can't open USB relay device: %d", (int)ftdiPortStatus);
return;
}
//Turn off bit bang mode
ftdiPortStatus = FT_SetBitMode(*usbRelayPointer, 0x00,0);
if (ftdiPortStatus != FT_OK)
{
NSLog(#"Electronics error: Can't set bit bang mode");
return;
}
// Reset the device
ftdiPortStatus = FT_ResetDevice(*usbRelayPointer);
// Purge transmit and receive buffers
ftdiPortStatus = FT_Purge(*usbRelayPointer, FT_PURGE_RX | FT_PURGE_TX);
// Set the baud rate
ftdiPortStatus = FT_SetBaudRate(*usbRelayPointer, 9600);
// 1 s timeouts on read / write
ftdiPortStatus = FT_SetTimeouts(*usbRelayPointer, 1000, 1000);
// Set to communicate at 8N1
ftdiPortStatus = FT_SetDataCharacteristics(*usbRelayPointer, FT_BITS_8, FT_STOP_BITS_1, FT_PARITY_NONE); // 8N1
// Disable hardware / software flow control
ftdiPortStatus = FT_SetFlowControl(*usbRelayPointer, FT_FLOW_NONE, 0, 0);
// Set the latency of the receive buffer way down (2 ms) to facilitate speedy transmission
ftdiPortStatus = FT_SetLatencyTimer(*usbRelayPointer,2);
if (ftdiPortStatus != FT_OK)
{
NSLog(#"Electronics error: Can't set latency timer");
return;
}
}
}
Disconnection is fairly simple:
ftdiPortStatus = FT_Close(*electronicsPointer);
*electronicsPointer = 0;
if (ftdiPortStatus != FT_OK)
{
return;
}
Writing to the serial device is then pretty easy:
__block DWORD bytesWrittenOrRead;
unsigned char * dataBuffer = (unsigned char *)[command bytes];
//[command getBytes:dataBuffer];
runOnMainQueueWithoutDeadlocking(^{
ftdiPortStatus = FT_Write(electronicsCommPort, dataBuffer, (DWORD)[command length], &bytesWrittenOrRead);
});
if((bytesWrittenOrRead < [command length]) || (ftdiPortStatus != FT_OK))
{
NSLog(#"Bytes written: %d, should be:%d, error: %d", bytesWrittenOrRead, (unsigned int)[command length], ftdiPortStatus);
return NO;
}
(command is an NSData instance, and runOnMainQueueWithoutDeadlocking() is merely a convenience function I use to guarantee execution of a block on the main queue).
You can read raw bytes from the serial interface using something like the following:
NSData *response = nil;
DWORD numberOfCharactersToRead = size;
__block DWORD bytesWrittenOrRead;
__block unsigned char *serialCommunicationBuffer = malloc(numberOfCharactersToRead);
runOnMainQueueWithoutDeadlocking(^{
ftdiPortStatus = FT_Read(electronicsCommPort, serialCommunicationBuffer, (DWORD)numberOfCharactersToRead, &bytesWrittenOrRead);
});
if ((bytesWrittenOrRead < numberOfCharactersToRead) || (ftdiPortStatus != FT_OK))
{
free(serialCommunicationBuffer);
return nil;
}
response = [[NSData alloc] initWithBytes:serialCommunicationBuffer length:numberOfCharactersToRead];
free(serialCommunicationBuffer);
At the end of the above, response will be an NSData instance containing the bytes you've read from the port.
Additionally, I'd suggest that you should always access the FTDI device from the main thread. Even though they say they support multithreaded access, I've found that any kind of non-main-thread access (even guaranteed exclusive accesses from a single thread) cause intermittent crashes on the Mac.
Beyond the cases I've described above, you can consult the D2XX programming guide for the other functions FTDI provides in their C library. Again, you should just need to move over the appropriate code from the samples that have been provided to you by your device manufacturer.
I was running into a similar issue (trying to write to the EntTec Open DMX using Objective-C), without any success. After following #Brad's great answer, I realized that you also need to toggle the BREAK state each time you send a DMX packet.
Here's an example of my loop in some testing code that sends packets with a 20 millisecond delay between frames.
while (1) {
FT_SetBreakOn(usbRelayPointer);
FT_SetBreakOff(usbRelayPointer);
ftdiPortStatus = FT_Write(usbRelayPointer, startCode, 1, &bytesWrittenOrRead);
ftdiPortStatus = FT_Write(usbRelayPointer, dataBuffer, (DWORD)[command length], &bytesWrittenOrRead);
usleep(20000);
}
Hope this helps someone else out there!