Call to arms | Teensy + SDRAM = true

From memory, the PD chip is only meant to power the second USB-C port (not the board) and it only does that if you bridge the middle pad (which is connected to the second USB-C port's V+ lines) to the PD's output. If you want the USB-C port to not do PD / only supply 5V (from the board's 5V supply) then you need to bridge the middle pad to the other side.
 
jmarsh said:
Changing the BMCRx registers would only help if the issues are caused by reads and writes happening to the same locations at the same time, and they were being reordered incorrectly with respect to each other. I still can't see how that would occur without it already being a race condition - if two peripherals are accessing the same memory without any sort of synchronization to control which one goes first, you can't predict which one will be served first.
Click to expand...
Replying to myself here: I have (very painfully) discovered how this reordering can be a problem!

In my USB host code, I use this very specific sequence to add new transfers to a queue head:
Code: 
  usb_transfer* p = dummy.release(); // copy dummy ptr
  dummy.reset(head);                 // head becomes new dummy
  head->token.status = 0x40;         // set inactive+halted
  *p = *head;                        // copy over dummy (becomes new head)
  cache_flush(p);                    // ensure new qTD data is updated _before_ activating
  cache_flush(head);
  cache_sync();                      // ensure cache flush has completed
  p->token.status = 0x80;            // set old dummy/new head active
  cache_flush(p);                    // flush (triggers overlay if QH is idle)

The tricky thing that may not be obvious here is that the USB Host Controller is constantly checking the memory pointed to by p to see if the status is set to active. That's why cache_flush() is called on p twice; once when the contents are initially copied from head (followed by a dsb instruction to ensure it completes) then again after token.status is set to active, to ensure that the status is the final modification made to the physical memory. But from what I was seeing, the host controller was reading the status as active when the other fields were still set to incorrect values, as if they had not been updated before the status.

The fix, as has been mentioned earlier in the thread, was to set the SEMC_BMCR0 and SEMC_BMCR1 registers to 0x81 to prevent reads/writes to the SDRAM from being reordered by the SEMC controller. This ensures the cache lines evictions occur in the correct order.
 
Dog bones boards arrived today.

I've soldered the bootloader chip on and on pressing the button I'm getting 3 red blinking lights.

According to pjrc store link that means it's not recognising the flash chip. Realised I've used W25Q128JVPQ instead of dogbones recommended W25Q128JVPIM. Is this chip incompatible?
 
theboot900 said:
Dog bones boards arrived today.

I've soldered the bootloader chip on and on pressing the button I'm getting 3 red blinking lights.

According to pjrc store link that means it's not recognising the flash chip. Realised I've used W25Q128JVPQ instead of dogbones recommended W25Q128JVPIM. Is this chip incompatible?
Click to expand...
Yeah, that flash chip won't work. See the "supported chips" section here: https://www.pjrc.com/store/ic_mkl02_t4.html
 
You must log in or register to reply here.
Back
Top