It is complaining about the descriptors, strange because those are the same used for all other boards in the last 10 years. Have you tried one of the supported demos? is the result the same?
Is that an USB3 port? I don't understand why it says 64 bytes is not a legal packet size, it is.
At the end it is the set configuration command to fail.
Giovanni
USB on STM32F750.
Moderators: RoccoMarco, barthess
- Giovanni
- Site Admin
- Posts: 14444
- Joined: Wed May 27, 2009 8:48 am
- Location: Salerno, Italy
- Has thanked: 1074 times
- Been thanked: 921 times
- Contact:
Re: USB on STM32F750.
I have tried to eliminate as many variables as possible:
I'm using a supported disco board (STM32F746 discovery) with the supported CDC demo.
Trying to get ANYTHING working....
(Well, the blinky part still works).
I have enabled SD6 and I'm trying to get serial output on the arduino pins.
This runs into an unhandles exception in the first call to sdWrite. I am monitoring the right pins with the logic analyser as I've tested witht he 150 toggles.
Update: I have a homebuilt software-serial output working on PC6 at 1.68Mbps. Turns out my "delay 1 microsecond" timing is a bit off. Oh well. That's the fun of the logic analyser you can adjust the baudrate after the fact...
I'm using a supported disco board (STM32F746 discovery) with the supported CDC demo.
Trying to get ANYTHING working....
(Well, the blinky part still works).
I have enabled SD6 and I'm trying to get serial output on the arduino pins.
Code: Select all
static char buf[128];
/*
* This is a periodic thread that does absolutely nothing except flashing
* a LED attached to TP1.
*/
static THD_WORKING_AREA(waThread2, 256);
static THD_FUNCTION(Thread2, arg) {
int t;
t = 0;
(void)arg;
chRegSetThreadName("sdwriter");
palSetPadMode (GPIOC, 6, PAL_MODE_ALTERNATE(8));
palSetPadMode (GPIOC, 7, PAL_MODE_ALTERNATE(8));
sdStart(&SD6, NULL);
#if 0
palSetPadMode (GPIOC, 6, PAL_MODE_OUTPUT_PUSHPULL);
for (t=0;t<150;t++) {
palTogglePad (GPIOC, 6);
chThdSleepMilliseconds (10);
}
#endif
while (true) {
// palTogglePad (GPIOC, 6);
//sprintf ((void*)buf, "test %d\r\n", t++);
strcpy (buf, "test xx\r\n");
buf[5] = '0' + (t/10)%10;
buf[6] = '0' + (t )%10;
sdWrite (&SD6, buf, 9);
// mywrite (buf);
chThdSleepMilliseconds(500);
}
}
This runs into an unhandles exception in the first call to sdWrite. I am monitoring the right pins with the logic analyser as I've tested witht he 150 toggles.
Update: I have a homebuilt software-serial output working on PC6 at 1.68Mbps. Turns out my "delay 1 microsecond" timing is a bit off. Oh well. That's the fun of the logic analyser you can adjust the baudrate after the fact...
Re: USB on STM32F750.
OK. I now have SD6 working. Turns out
the "sdWrite" is wrong. (I now have a MYSD define that currently resolves to SD6, so I can easily switch U(S)ARTs. Mywrite is the software serial now on PC7 (formally RX, but for now...).
I thought I would initially not complicate things with chprintf, but chprintf works, and sdWrite doesn't.
Code: Select all
strcpy (buf, "test xx\r\n");
buf[5] = '0' + (t/10)%10;
buf[6] = '0' + (t )%10;
// sdWrite (&MYSD, (void*) buf, 9);
mywrite (buf);
chprintf ((BaseSequentialStream *)&MYSD, "Test %d.\r\n", t);
the "sdWrite" is wrong. (I now have a MYSD define that currently resolves to SD6, so I can easily switch U(S)ARTs. Mywrite is the software serial now on PC7 (formally RX, but for now...).
I thought I would initially not complicate things with chprintf, but chprintf works, and sdWrite doesn't.
Re: USB on STM32F750.
OK. I've got the '750 working on the Discovery board.
The '295 was from the '746 discovery and the next one is from the '750.
Code: Select all
Test 295.
Welcome, compiled Jun 3 2020 13:41:30
Test 0.
Test 1.
Test 2.
The '295 was from the '746 discovery and the next one is from the '750.
- Giovanni
- Site Admin
- Posts: 14444
- Joined: Wed May 27, 2009 8:48 am
- Location: Salerno, Italy
- Has thanked: 1074 times
- Been thanked: 921 times
- Contact:
Re: USB on STM32F750.
USB serial implements the "channels" interface, the write method is chnWrite().
sdWrite() is specific of serial ports.
Giovanni
sdWrite() is specific of serial ports.
Giovanni
Re: USB on STM32F750.
I have, for now, given up on getting USB to work.
I can print test-strings to the (real!) serial port using chprintf.
I am now implementing my "shell" and ...
crashes.
How do I read a character from a SD1 device?
I can print test-strings to the (real!) serial port using chprintf.
I am now implementing my "shell" and ...
Code: Select all
if (streamRead(chp, (uint8_t *)&ch, 1) == 0) return;
How do I read a character from a SD1 device?
Re: USB on STM32F750.
Giovanni, I changed to "streamGet" instead of "streamRead" and now that works. Now it crashes just a short while later.
When trying to debug this, it crashes after printing 15 characters of the first debug message.
Could it be that the context switches are not working correctly? I vaguely remember you saying something about a compiler bug.
I googled for "recommended compiler" but don't get any relevant hits.
https://www.google.com/search?q=chibios ... e&ie=UTF-8
I've been using chibios since before Ubuntu 16.04 came out and when ubuntu 16.04 came out, I was happy to find that the out-of-the-box compiler worked flawlessly. Two years later I tested 18.04 and there the arm compiler didn't work. So on my work computer I've stayed on 16.04. It's worked fine since 2016. This compiler bug is triggered by something changed in the code?
When trying to debug this, it crashes after printing 15 characters of the first debug message.
Could it be that the context switches are not working correctly? I vaguely remember you saying something about a compiler bug.
I googled for "recommended compiler" but don't get any relevant hits.
https://www.google.com/search?q=chibios ... e&ie=UTF-8
I've been using chibios since before Ubuntu 16.04 came out and when ubuntu 16.04 came out, I was happy to find that the out-of-the-box compiler worked flawlessly. Two years later I tested 18.04 and there the arm compiler didn't work. So on my work computer I've stayed on 16.04. It's worked fine since 2016. This compiler bug is triggered by something changed in the code?
- Giovanni
- Site Admin
- Posts: 14444
- Joined: Wed May 27, 2009 8:48 am
- Location: Salerno, Italy
- Has thanked: 1074 times
- Been thanked: 921 times
- Contact:
Re: USB on STM32F750.
Are you using the compiler from repositories?
That never worked well. Please use the official GCC from ARM.
Giovanni
That never worked well. Please use the official GCC from ARM.
Giovanni
Re: USB on STM32F750.
It worked well for me for quite a while.
I just went to
https://developer.arm.com/tools-and-sof ... /downloads
and installed that. Less hassle than I remember from 2014/2015 when I did that too.
I just went to
https://developer.arm.com/tools-and-sof ... /downloads
and installed that. Less hassle than I remember from 2014/2015 when I did that too.
Re: USB on STM32F750.
New compiler seems to work better.
In i2cMasterTransmitTimout there is a big osalDbgCheck. I've split it into multiple lines like this:
... to ffigure out which one is triggering. It's the rxbytes one.
The way I understand things, EITHER you specify rxbytes zero OR you need rxbuf to be nonzero, right?
My call is:
and the debugger tells me:
What's going on?
In i2cMasterTransmitTimout there is a big osalDbgCheck. I've split it into multiple lines like this:
Code: Select all
osalDbgCheck(i2cp != NULL);
osalDbgCheck(txbytes > 0U);
osalDbgCheck(txbuf != NULL);
osalDbgCheck((rxbytes == 0U) || ((rxbytes > 0U) && (rxbuf != NULL)));
osalDbgCheck(timeout != TIME_IMMEDIATE);^M
The way I understand things, EITHER you specify rxbytes zero OR you need rxbuf to be nonzero, right?
My call is:
Code: Select all
i2cMasterTransmitTimeout(&MY_I2C, a>>1, txbuf, 2, NULL, 0, tmo);
and the debugger tells me:
Code: Select all
Breakpoint 2, chSysHalt (
reason=reason@entry=0x8006744 <__func__.8824> "i2cMasterTransmitTimeout")
at chibios/os/common/ext/ARM/CMSIS/Core/Include/cmsis_gcc.h:142
142 __ASM volatile ("cpsid i" : : : "memory");
(gdb) up
#1 0x00203530 in i2cMasterTransmitTimeout (addr=addr@entry=64,
txbuf=txbuf@entry=0x2004ff48 "", txbytes=txbytes@entry=2,
rxbuf=rxbuf@entry=0x0, rxbytes=rxbytes@entry=0, timeout=40,
i2cp=0x20000800 <I2CD1>) at chibios/os/hal/src/hal_i2c.c:182
182 osalDbgCheck((rxbytes == 0U) || ((rxbytes > 0U) && (rxbuf != NULL)));
(gdb)
What's going on?
Who is online
Users browsing this forum: No registered users and 18 guests