search

IWPengineering / IWP_Firmware_2.0_Beta

Rewrite of IWP Firmware for PIC24F32KA302 (3.3V version of previous micro)
0 stars 1 forks source link

I2C Isn't Working #2

Closed Ken-Kok closed 8 years ago

Ken-Kok commented 8 years ago

Everything send via I2C Drivers is getting the following:

Setup Write to ['240'] + NAK

This is happening many times during INIT (trying to write time to RTCC), and once per second (as specified) for reading the clock

Ken-Kok commented 8 years ago

Today I rolled my own I2C Functions, primarily based on the currently implemented functions in 1.0, but with slight modifications (software reset is more robust, ENUM based error handling, and Idle built into Write, etc).

I will test this code either tonight at home or at Collab. Hopefully it works :)

Ken-Kok commented 8 years ago

Briefly tested my I2C Functions last night. They seemed to be trying to set up various writes to various places, but nothing seemed to be getting through with valid data.

Will do more testing tonight and tomorrow to try to iron out the bugs.

Ken-Kok commented 8 years ago

Working on this bug has been delayed until I can get the _AddressError bug to stop happening. Unfortunately, the program is crashing in under 1 sec, which means I'm never trying to read.

It looks like writing isn't working either. The bus is trying to write out some bits that don't look like what I am asking for, but I'll have to dive into that deeper later when I get the chance.

Worst case, I will copy the 1.0 I2C Driver

Ken-Kok commented 8 years ago

Now that _AddressError bug has stopped, this will be debugged next.

Ken-Kok commented 8 years ago

In 335c3eccad31b73fd7ca2e9603adef47ed27a00c and 780437534b2f5a7b94c749d290807c12d7bc13c8, I went ahead and tried to find some problems with the I2C driver.

  1. Disabled I2C before reset. Also added the init that is in 1.0 firmware.
  2. During I2C init, I went ahead and set it up so that the enable bit is set right at the end of the function, after the I2C clock is set.
  3. Added a breakout condition for software reset, and forced it to toggle SCL a minimum of 9 times, which is the maximum number of held bits.
Ken-Kok commented 8 years ago

Even though some problems are fixed, the driver currently does...nothing.

That is to say that the RTCC nacks everything, and always returns all 1's. This means that it isn't ever asserting the line low. Dead hardware?

Ken-Kok commented 8 years ago

It appears that this is fixed, it seems to be a hardware issue. Will commit code soon

Ken-Kok commented 8 years ago

Fixed in 3b768c08914c3cfff185b899983ed34371dc1e3d