USB on STM32F750.

[Giovanni]

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

[rew]

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.

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...

[rew]

OK. I now have SD6 working. Turns out

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.

[rew]

OK. I've got the '750 working on the Discovery board.

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]

USB serial implements the "channels" interface, the write method is chnWrite().

sdWrite() is specific of serial ports.

Giovanni

[rew]

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 ...

Code: Select all

  if (streamRead(chp, (uint8_t *)&ch, 1) == 0) return;

crashes.

How do I read a character from a SD1 device?

[rew]

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?

[Giovanni]

Are you using the compiler from repositories?

That never worked well. Please use the official GCC from ARM.

Giovanni

[rew]

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.

[rew]

New compiler seems to work better.

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

... 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:

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?