Project Logs

Collapse logs

• Loggin'

  Ole Andreas Utstumo • 09/07/2019 at 20:14 • 0 comments

  Fatfs is working with the new flash chip, the USB MSC services are running, the ECG front end is now also running smoothly via SPI and we're logging data to files.
  

  Binary data straight from the front end obviously won't look good in a text editor...
  

  And if you're working with STM32 and haven't tried out SEGGER's excellent software packages, I strongly urge you to. They provide by far the most handy tools I've used yet for embedded debugging. The real time variable graphing tool is damn cool:
  
  

  
  

• Blinkin'.

  Ole Andreas Utstumo • 09/01/2019 at 17:51 • 0 comments

  All good so far.

• Mounted.

  Ole Andreas Utstumo • 09/01/2019 at 17:48 • 0 comments

  Three cards were mounted a while back. Hand mounting SMD components on a PCB backside is as usual a pain in the arse... I will hopefully never fall for that one again.
  

• Design files uploaded

  Ole Andreas Utstumo • 06/29/2019 at 17:35 • 2 comments

  ... And can now be found on the main project page. I hope I didn't leave anything important out of the project folder :-)
  

• Finishing up design & ordering

  Ole Andreas Utstumo • 06/29/2019 at 15:24 • 2 comments

  I think I'm done routing for now. It all fits nicely in a small package.
  I'll also upload the files and gerbers after I've done some tidying up.
  

• Divided by rings

  Ole Andreas Utstumo • 06/28/2019 at 21:48 • 0 comments

  Isolating and looking at my power planes in KiCAD, they seem a bit more divided than I wished they were..

  The clearance in the design rules is set to 0.2 mm, and the copper fill strangely gives way to via annular rings in other layers... Looking at the 3D Viewer it's more obvious what's going on:

  The via pad stack has annular rings in layers where they are unused -- and the copper fill respects the clearance just as being told. Poking around on the internet revealed that other people had the same issue, however, only workarounds seem to be available at the moment... I'm not gonna dig too deep into KiCAD, so I will let this one rest for now.
  
  

• Recommendations are just that pt. 2

  Ole Andreas Utstumo • 06/20/2019 at 11:11 • 0 comments

  As Jan pointed out in the previous log, the solder on the battery contact pad will oxidize. If the resistance in the contact builds up too much, we can solve it by placing some metal more resistant to corrosion and oxidation, like gold on the pad.
  

  A quick search reveals that there are SMD components which can help us out.

  https://www.mouser.se/ProductDetail/Harwin/S70-332002045R?qs=sGAEpiMZZMu2RFV024JNkxXHxBnx8LODQgUeuJAN3z3EkEymqw5JaA%3D%3D

  I'll implement Jan's idea of having a triangle of contact points.
  
  Initially I'll just use the pads with solder, and have these as a backup :-)
  

• Recommendations are just that.

  Ole Andreas Utstumo • 06/16/2019 at 21:12 • 2 comments

  Okay, my initial plan was using a four layer PCB with power planes as the inner layers, and signals traversing the outermost layers, to make for painless routing. That is until I checked the price of a prototype series with blind and buried vias at PCBWay.
  Obviously there are a bit more steps to the production of buried via PCBs than your regular 1.6 mm double sided green wafers of crispbread, and for a hobby project it's way more than what I want to commit. So I'll still run with a four layer PCB to keep my power planes intact, and let the signal vias run through the entire PCB. Then we're at 70 USD for 10 30x30 mm boards.
  
  So here comes the next problem: The CR2032 holder I picked requires a damn large pad on the bottom side for contact with the negative side of the battery.
  Which makes through vias problematic in 50% of the boards area when placed on the back side. I can pull GND down to the battery terminal, but anything else will short to the battery..
  I quite like the simplicity of these kinds of holders, though...
  Maybe there is a trick we can pull? The datasheet for the battery holder recommends a footprint, but there's no one saying we can do our own interpretation. As long as we make robust mechanical and electrical contact we should be good. So
  Becomes
  Instead of resting the entire negative face of the battery on a gold treated copper pad we can make two "rails" that are almost right underneath the springs on top push the battery down. The pads will be surrounded by solder stop which might have more height than the pad:
  That would be bad news for our electrical contact, so we could try to gain control over this uncertain situation by adding solder paste to the pad.
  
  That should do the trick, and now we have freed the necessary space to route the rest!
  
  As some one pointed out in the comments below, solder will oxidize. Hopefully it will be a minor problem...
  To be continued...
  

• Recovering

  Ole Andreas Utstumo • 06/01/2019 at 16:40 • 0 comments

  Among the things that could have caused the mass storage device to crash is timing issues. As the datasheet suggests, a minimum deselect time between each word in the write cycle must be T_BP = 10 µs.

  The HAL framework has no delay function for microseconds, so unless you want to implement this yourself, you could employ a dirty trick like this:
  

          for(uint16_t k=1; k < 55; k++){
              asm("nop");
          }

  A "nop" is an instruction that does nothing, but occupies a certain number of clock cycles and therefore a tiny amount of time. However, if you start changing the core frequency of the MCU, then interesting things happen, which it truly did in my case. Resetting the clocks to default, checking the write operation in the scope and adjusting k in the delay cycle above we're back on track. However, increasing the clock of the SPI has marginal impact:

  Those blue streaks are two bytes written to the flash plus a control byte. The parts where nothing is happening is sadly overhead in the HAL libraries and can be overcome by writing your own SPI functions, or minimized by increasing the clock of the core. For my use it's good enough.
  

• Write speeds

  Ole Andreas Utstumo • 05/31/2019 at 15:08 • 2 comments

  I was unable to edit any files on the drive or format the drive itself untill I implemented the following function:

  int8_t STORAGE_IsReady_FS(uint8_t lun)
  {
    /* USER CODE BEGIN 4 */
  	if(MMC_disk_status()==0)
  		return (USBD_OK);
  	else
  		return USBD_FAIL;
    /* USER CODE END 4 */
  }

   Now the drive can be formatted at will in Windows, and the data is persistent.

  Nice, let's try copying a jpeg to the drive. 

  
  Copying a 1.52 MB file to the newly formatted drive took a solid 1 minute and 13 seconds..

  32STMCubeMX tells me I should have a baud rate of 2.0 MBits/sec, which equals approx 250 kB/s. Quite a bit of overhead there... Let's try a quick fix and crank up the clock speed. According to the datasheet for the flash IC, it should be able to handle 50 MHz. So let's set the SPI peripheral clock to 40 MHz and see what happens. I'm a bit too lazy to look up if the Prescaler in the CubeMX settings prescales the outbound SPI clock, or what it actually does, so let's start gently and increase the settings untill something breaks.

  20 MBit / sec should give us a 10x speed increase. 

  That didn't quite work... Let's turn the settings back for a second. The clock should not have surpassed what the SPI flash can handle..

  Damn, looks like I broke something. 

  Restoring the working project doesn't seem to cut it either. Now I'm stuck in a eternal loop waiting for the flash IC to clear it's busy flag...

View all 51 project logs