Project Logs

Collapse

• GreenPAK H-Bridge gate driver test

  Anders Helgesson • 4 days ago • 0 comments

  I've decided to skip the reading of the voltage from the 40 Volt PSU and use that pin as a fault output for the H-Bridge control. Now all the pins of the GreenPAK(SLG46826V) are in use. I'm now using a virtual input register in the GreenPAK to control the 40 Volt PSU and the MCU pin originally intended for this purpose has become the fault interrupt input.

  I connected it all up and it looks like this. The added test circuit breadboard with the LED's and lots of wires.

  The TPS module is set at 5 volt to power the H-Bridge and 40V PSU.

  Opto-couplers with 1k pulls ups are powered from the TPS module. They are controlled by the greenPAK.

  The load switch will be a stand in for the 40V PSU with a LED.

  Before I mentioned I would use a load switch for the H-bridge but since there is nothing to power there except for the pull ups, I've decided to use the EN pin on the TPS module instead. It's EN is sinked to ground by the GreenPAK to turn it off.

  Here is what the H-Bridge gate driver GreenPAK design now looks like.

  First the two 3-bit LUT's takes the MCU SPWM signals inverts the signals and outputs them to the H-Bridge gates. They also make sure that both signals can not be on at the same time. The fault signal is also sent taken into account as an extra safety, if a fault has been latched it can not drive the gates.

  The 4-bit LUT takes both MCU SPWM signals, TPS EN signal and the 40 Volt PSU signal. This makes it not possible to drive the gates without the 40 Volt PSU on. A DFF is connected to the output and if it's HIGH it will latch until cleared using the I2C controlled register.

  I noticed that the LED's I used have inbuilt resistors(for 5volts) on the positive side(anode), with the 1K pull up acts as a voltage divider. Using these kind of LED's for breadboarding should probably be avoided, when they make a voltage divider when you don't want one.

  Programming the new functionality. I've decided to make a general read_virtual_input_register and write_virtual_input_register. So it's easy to use these registers, there is 8 in total.

  I added the new simulate call state and some other code to make that work. I had to debug some code and fix some issues. Commands for resetting the fault condition and simulate a call have been added. I also added so I can access all the virtual input registers as well for testing.

  At first it didn't work like it should and it was because I had configured the 4-bit LUT the wrong way. Since I used this test circuit and not the live H-Bridge, no magic smoke event occured. After I reconfigured the 4-Bit LUT it started working as it should.
  I tested all the logic of the 4-Bit LUT and Injected 3.3 volts on each of the sPWM signals from the MCU to test the shoot-through protection. The H-Bridge gate driver works like it should and should protect the H-Bridge from blowing up.

• H-Bridge gate control design

  Anders Helgesson • 05/05/2025 at 20:34 • 0 comments

  To implement my H-Bridge gate driver in the GreenPAK I have to have a test circuit. I've decided to wire it up on a small breadboard.

  A 5 Volt PSU will power the 40 Volt PSU and H-Bridge opto-coupler pull-ups. A load-switch will turn on a LED and is a stand in for the 40 Volt PSU. The will opto-couplers are connected to LED's as well. I will be using a pin as output for the fault and it will turn on a LED.

  Here is the design for the gate-control in the GreenPAK.

  Here is how this should work. The 4-bit LUT checks the output signals, 5 Volt supply EN and 40 Volt PSU EN.

  It outputs a 1 if both SPWM channels are on at the same time, it also checks that the 40Volt PSU has been turned on and that the 5 Volt supply is also on. The 40 Volt PSU can not be turned on before the 5 Volt PSU this will also register a fault.
  It's latched by the DFF until reset by the MCU via one of the I2C virtual output registers.
  The SPWM LUT's inverts the logic and if it has a fault signal locks both channels so they make sure that the H-Bridge is off.

  The PSU's are also controlled by the MCU via the I2C virtual output registers.
  Now to test this design I have to wire up the test board and do some programming.

  I'm going to make used of the command mode of the phone. Fault reset command, would reset the DFF if a fault has occured. Bell ringer test command, when this command is activated and the handset placed back on, a timer starts and executes a simulated call by ringing the bells until the handset is picked up.

  With a test circuit there is no risk of something blowing up, while implementing the new Bell Ringer control.

• NVRAM erase command fix

  Anders Helgesson • 05/04/2025 at 19:30 • 0 comments

  I suspected that the document "In-System Programming Guide for SLG46824/6/7-A", that specifies some whole pages as reserved is wrong. Looking through the register definition in the datasheet there are some configuration that exist in the excluded pages 4 and 12. Perhaps that table was just for the SLG46824?

  Including page 4 and 12 in the erase command fixed the problem and I could flash it properly.

• Keypad works but NVRAM erase command does not

  Anders Helgesson • 05/03/2025 at 20:15 • 0 comments

  The GreenPAK keypad scanning design with the new pinout looks like this.

  The columns share the same LUT and to keep it simple and just one I2C read to get the key pressed. I'm reading 3 bytes. Byte 0x74, Byte 0x75 and Byte 0x76. These contains the matrix inputs and LUT outputs used.
  These are used to determine which key was pressed. Since I don't change the pinout often. I'm just going to update the code with the new pinout, it's just simpler. I updated the bitmask with the new setup for the column pins, for the rows I were reading the LUTs already so nothing have changed here. It now works again. I've flashed the new design onto the GreenPAK.

  My erase command doesn't seem to properly erase the device. The new code and pinout works if I write directly to the registers.
  If I use my NVRAM erase, flash and then reset the device it doesn't work. I'm guess my erase command does not erase all of the NVRAM properly. I have to go through and get the NVRAM erase to work properly. I have to write some debug features to read and compare the NVRAM and registers.

  So it wasn't a problem with the schmitt triggers, so I put them back on the column inputs and tested it. It works perfectly and might even be more robust with the schmitt triggers on the column inputs.

• NVRAM erasing, flashing and a problem

  Anders Helgesson • 05/02/2025 at 21:40 • 0 comments

  With the research I did before I implemented the nvram erase command for the GreenPAK(SLG46826). I erased the NVRAM and checked it. It worked perfectly.

  With the now blank GreenPAK I decided to flash my new design. I powered everything up and it didn't work. I check the debug messages and interrupt from the GreenPAK didn't latch.

  I remembered that I had added schmitt triggers on the column inputs, so I removed them again. Back to flashing, now I erased and accidentally flashed the old project file again. That was wasteful. I should have written to the registers instead to test.
  I wrote the new design to the registers and the interrupt was working again. However when I pressed the keys, it's not playing back the correct key tones. Why?

  Well, I forgot about the way it works, the GreenPAK sends an interrupt when a key is pressed. The MCU gets this and reads which key is being pressed through reading the registers of the GreenPAK over I2C. Instead of reading the LUT's I set it up to read the pins. Now this was a bad choice as the pinout has changed.

  I have to rewrite the code for this. I'm going to have it read the LUTS directly instead. Time to read the datasheet again.

  One step forward, two steps back but I'm on the right track.

• Erasing the NVRAM pages in the GreenPAK(SLG46826)

  Anders Helgesson • 04/30/2025 at 19:11 • 0 comments

  I looked at how to erase the NVRAM in the GreenPAK(SLG46826) and I found this.

  This was not included in the datasheet but in another document (In-System Programming Guide for SLG46824/6/7-A).

  This is interesting as my software writes to all but the last service page. I found this table and it tells me that writing to the reserved pages could also be skipped. I'll put it in the comments for the write command for now.

  I need to erase pages 0-3 and 6-11. I can skip the reserved, protection and service pages.

  Erasing the NVRAM is done through the ERSE register. It is also used to erase the emulated eeprom. The datasheet says "The ERSR register is located on I2C Block Address = 000b, I2C Word Address = E3H."

  The ERSE Register (E3H) Bit Function Description looks like this.

  If I understand it correctly the ERSEB3 - ERSEB0 are used like this to set which page that should be erased.

  The last 4 bits must be used to select a page number from 0-15. No mention of this but I assume it is how it works.

  So for example 10001011b would erase NVRAM page 11, 10011011b would erase emulated EEPROM page 11. I might have mentioned before that the emulated EEPROM can not be used by the GreenPAK it self but could be accessed through I2C to store calibration and other settings that do not change. It also has the limitation of 1000 writes like the NVRAM.

  Datasheet notes also says:

  "Upon receipt of the proper Device Address and Erase Register Address, the SLG46824/6/7-A will send an ACK. The device will then be ready to receive Erase Register data. The SLG46824/6/7-A will respond with a non-compliant I2C ACK after the Erase Register data word is received. Please reference the SLG46824/6/7-A errata document (revision XC) posted on Renesas’s website for more information.

  The addressing device, such as a Bus Master, must then terminate the write operation with a Stopcondition. At that time, the GPAK will enter an internally self-timed erase cycle, which will be completed within tER (max 20 ms). While the data is being written into the Memory Array, all inputs, outputs, internal logic, and I2C access to the Register data will be operational/valid. After the erase has taken place, the contents of ERSE bits will be set to "0" automatically. Erase will be triggered by Stop Bit in I2C command."

  I guess I have to take that into account when writing my nvram erase command.

  It also says:
  "An Acknowledge Polling routine can be implemented to optimize time sensitive applications that would prefer not to wait the fixed
  maximum write cycle time (tWR) or erase maximum cycle time (tER). This method allows the application to know immediately when the Serial EEPROM emulation write/erase cycle has completed, so a subsequent operation can be started. 

  Once the internally self-timed write/erase cycle has started, an Acknowledge Polling routine can be initiated. This involves repeatedly sending a Start condition followed by a valid Device Address byte (NVM block address) with the R/W bit set at Logic 0. The device will not respond with an ACK while the write cycle is ongoing. Once the internal write/erase cycle has completed, emulated EEPROM will respond with an ACK, allowing a new read, erase, or write operation to be immediately initiated.

  The length of the self-timed write cycle (tWR) and self-timed erase cycle (tER) is defined as the amount of time from the Stop condition that begins the internal write operation to the Start condition of the first Device Address byte that includes NVM address(A9 = 1; A8 = X) sent to the SLG46826 that it subsequently responds to with an ACK."

  I could use this to make the erase command quicker instead of waiting for 21ms per page erase. I guess since some values are already 0 a page erase would take less than the max of 20ms specified in most cases.

  Before I had problems with setting the first 2-bit LUT0, maybe the erase command will make it useable? I could read from it but not set it in both...

  Read more »

• Revisiting the bell ringer

  Anders Helgesson • 04/29/2025 at 04:25 • 0 comments

  So I have no gate-driver for my H-Bridge, it is a P-Channel MOSFET(transistor controlled) on the high side and N-Channel MOSFET(now logic level) on the low side.

  Why do I need a gate-driver?
  The opto-couplers isolating and level-shifting the SPWM signals, are using pull ups. This means that logic low = high(ON) on the H-bridge and logic high = low(OFF) on the h-bridge.

  I have to make sure that both sides of the H-bridge are not on at the same time, as this would cause shoot-through. With the inversed logic it would mean that if there is problem with the MCU for example a power loss. It would turn on both sides of the H-Bridge. If this happens when the PSU and H-Bridge are powered shoot-through will most definetly happen.

  Why didn't I need it before?
  Before I had programmed a PIC to output a square-wave at 25Hz which was just turned on to ring the bells. I didn't care about the PIC as it would be easily and cheaply replaceable if it blew up.

  After that I tried the H-Bridge motor driver IC. It already had protection built-in. It however it didn't like SPWM signals.

  Now with the new logic-level mosfets, I can control it easily with 5 volts to get full activation and power to ring the bells.

  I'm thinking that I can use the leftover resources in the GreenPAK to design a gate-driver inverting the signals and protecting from shoot-through. I'm also going to use it to control the loadswitches to the 40V PSU, h-bridge and if there is resources left over monitor the voltage from the 40V PSU.

  Here is the current usage of the GreenPAK(SLG46826).

  I have 7 free pins.

  I need 4 pins for the H-bridge control.
  I need 2 pins for the Load switches.
  The last pin could be used to monitor the voltage from the 40 volt PSU.

  I'm thinking of using this new pinout for the new design.

  Since I might use an ACMP to measure the PSU voltage when it's on, I've moved the pins around.

  Before I add functionality I need to make sure that the functionality I had is still working with the new pinout. It will make it easier to debug. 

  I didn't implement a NVRAM erase command in my GreenPAK programming software so I have to make that so I can erase the NVRAM for programming it with the new pinout.

  When this is done I can start making the h-bridge control in the GreenPAK.

• Moving things around

  Anders Helgesson • 04/27/2025 at 18:30 • 0 comments

  I've been working on the project during soem mornings and spare time.

  Here is what I've done.
  I used one of the small breadboards to make a interface board for the keypad and bell ringer stuff. It's currently just used for the keypad but will also be used to interface the MCU with the PSU and H-bridge. So now the keypad is housed in the DIAVOX.

  Looks like  this now.

  Moving the mainboard into the DIAVOX, introduced a new problem with the reset functionality. It looks like the switch position is just used to get a edge not to be a zone where the user can hold the switch. In the body there is a spring and the window of holding the switch in the reset area is gone. Thus I removed the reset switch entirely from the design. I'm just using the handset switch now and have the reset be executed on the edge when the handset is placed on. After the reset state is finished it just moves to the idle state, which is a better approach.

  I cut the trace connecting the R-key to the keypad so I can use it.

  I've moved the DAC to the big breadboard and implemented a new filter for it. There is no distortion or buzz anymore. The shortened I2C connection made it very stable. Before the I2C implementation could panic the mcu if I bumped the I2C cables. Putting my finger on the I2C lines doesn't cause any problem just a slight reduction in playback speed that is audible.

  I freed up an SPI interface for the new SPI DAC by moving some pins around, currently though 2 of it's pins are used by the PIO HS-I2C to drive the I2C DAC.

  When wiring up the SPI DAC I will make sure that it and the filter takes up minimal space on the breadboard. The new filter is tuned for tones only, using an active Sallen-Key low-pass filter with a 2 kHz cutoff. In hindsight having the ability to playback voice wouldn't be a bad idea for the command menu for example. I'll put that on a list for now.

  Now you might be wondering if I have a working DAC without problems why do I switch to an SPI DAC?

  Well, I've never used an SPI device before, so it's all for learning. Which is the point of this project anyway. The final design will most likely use an SPI DAC anyway.

  I've soldered modules I need and I've started redesigning the PSU and H-bridge for the bell ringer.

  Here they are, level shifters, load switches and SMPS modules.

  Next I will work on getting the bells working again and setting up the levelshifters for the modem and codec.

• When in need

  Anders Helgesson • 04/17/2025 at 21:43 • 0 comments

  The other day, I went to hardoff which is a second hand shop in Japan. They have a junk corner and I found this.

  The Shimadzu Kalnew, a stereo microscope with a shared camera port. 15x eye pieces and adjustable from 0.75x to 3.0x magnification.

  
  It's a heavy, sturdy thing with a rotating base. The working distance is great even without a reduction barlow lens. The lights are broken but can easily be replaced with a ring array of LEDs. I will not use the underlighting and I could make a new base for electronics work.

  What did I pay for this thing? 3300 yen. :)

  The optics are very clear, I used my cellphone as light and checked out the new Japanese bills.

  There is no auxiliary or protective lens, I don't want solder under it without something keeping the fumes or splashes out.

  Looking around at the hard off camera section I found, a 43.5mm UV or polarizing filter. Honestly I got fed up searching through the overfilled boxes so I got it anyway knowing that it wouldn't fit as the fitting on the microscope is 44mm. But I fixed that with PTFE tape. It's not perfect, a bit misaligned and I might have lost a bit of clarity. It will do until I find a proper one. You might be able to see it fitted to the microscope in the pictures. I also taped over the camera port as it had no cap on it.

  I'll be on the look out for a 0.5x barlow, filter or protective lens at 44mm. I might get lucky. 10x eye pieces wouldn't be so bad either. This was a big win for me as I don't have a huge budget for this project to buy tools.

• Olimex 4G LTE module problem and not a fluke

  Anders Helgesson • 04/15/2025 at 20:54 • 0 comments

  So looking over the parts I needed for the next step, I noticed that on the Olimex 4G LTE modem module, two SMD capacitors are not mounted properly.

  I wanted to measure to see if they have contact with the pad, so I took out my multimeter. A Fluke 83V, I noticed that one of the leads were very loose so I removed it and checked the plug. The connector inside was bent so I decided to bend it back a bit so it wouldn't be so loose. Bad idea, the metal in the connector must have been some aluminium alloy as it snapped off. It was not a fluke, it was my fault, checking the other lead it has a X cut instead of a single cut in the lead connector.

  So I have to replace the plug...

  Anyway, This is what the capacitors look like. 

  One of them is lifted might not even have a connection with the board. Shouldn't have passed inspection. I'll fix that later.

  Before, I tried using a 40volt H-Bridge Motor driver IC to drive the bells. The problem with that approach was that the IC would filter out the SPWM signals and I would end up with a square wave. Looking over the original H-bridge design, It should have had logic level N-Channel mosfets for the low side but, I put normal N-Channel mosfets there. This explains why it doesn't work properly.

  I've ordered some more parts I need, including mosfets and parts for the modem, codec and a new plug for the multimeter.

View all 58 project logs