MTCH112

[fixup]

Buenas tardes,
Seré breve, estoy en un proyecto en el que he de utilizar sensores de proximidad. He elegido el MTCH112 el cual lo controlo vía i2c, hasta ahí bien. Según el datasheet a este dispositivo es posible cambiarle la dirección i2c. Le cambio la direccion sin desconectar la alimentacion y funciona bien, es decir funiona bien con la direccion nueva. El problema surge cuando le quito la alimentación volviendo a coger de nuevo la dirección por defecto (0xE6).

 ¿Alguno de ustedes tiene experiencia con estos dispositivos?


El caso es que el datasheet de la DemoBoard para MTCH112 dice esto:
"The MTCH112 controller uses i2c protocol (and bus) to communicate with a host controller. In the case where multiple MTCH112 controllers are used in the same system, or the MTCH112 is used on an i2c bus where its slave address is already assigned to another device, the user has the ability to assign a new i2c address to the MTCH112 to avoid any conflict."

Un saludo
 Alberto

[RICHI777]

Hola, primero aclaro que nunca use ese dispositivo, pero leyendo el data sheet veo que posee EEPROM con lo cual sería lógico que el cambio de address debería persistir ante el corte de energía. Esperaste de 5 a 10 ms después del cambio de address ? Digo para darle tiempo a la EEPROM para que escriba el dato.

Si no encontrás la solución acá te paso un doc de Texas que explica como resolver problemas de múltiples devices pero usando hardware externo

http://www.ti.com/lit/an/scaa106/scaa106.pdf

Saludos !

[fixup]

Hola Richi
Muchas gracias por tu respuesta.

Es muy curioso lo que pasa con el MTCH112. Fíjate en la secuencia.

1º Con el pic inicializo programando una nueva dirección y acto seguido leo con la dirección que le he programado sin desconectar la alimentación. => Funciona perfectamente
2º Con el pic inicializo programando una nueva dirección espero unos segundos y apago alimentación, enciendo alimentación=> Ya no funciona. Hay que acceder con la dirección por defecto 0xE6.

Aqui viene lo curioso.

Sin mas modificaciones lo meto en el Serial PICKit y con una GUI que tiene MTCH112 y detecta la dirección nueva. Lo se porque la visualiza en el programa, pero con un analizador lógico veo que accede con la dirección 0xE6 que el la dirección por defecto.

Que te parece? Una p locura. Llevo ya 15 horas buscando una solución sin acudir a multiplexores i2c. Eso me suena a un bug del MTCH112.

Un saludo

[RICHI777]

EL kit detecta que cambiaste la dirección de la memoria ? pero accede fisicamente como 0xE6 ??? Si es así es rarisimo. Posteaste en un el foro de microchip ?

Saludos !

[KILLERJC]

Yo lo primero que hice fue buscar un errata pero no aparece nada, asi que no va a quedar otra que postear en el foro de microchip

[fixup]

Buenas, al final he optado por usar un pic10 y hacer un retardo a la conexión en el pin de reset, de esta manera voy configurando en cascada cada uno de ellos cuando arranco en una ventana de 1,5 segundos para cada MTCH112. Pues casi mejor así, dado que si necesito cambiarlo no tengo que preocuparme de nada, simplemente cambio y listo, facilitando así el mantenimiento del invento.

Un saludo
 

[RICHI777]

Excelente ! Y bueno responder cuando uno obtiene una solución.

Saludos !

[DominusDRR]

Saludos. En alguna parte leí que el MTCH112 es en realidad un PIC, y como tal, tiene bugs en el firmware, posiblemente debas actualizar el firmware interno. Lo mejor sería levantar un ticket técnico en MCHP.

[KILLERJC]

Saludos. En alguna parte leí que el MTCH112 es en realidad un PIC, y como tal, tiene bugs en el firmware, posiblemente debas actualizar el firmware interno. Lo mejor sería levantar un ticket técnico en MCHP.

No se donde habras leido eso pero. Es tan absurdo como suena. Mas que firmware, de silicio cuando el integrado no posee un firmware programable.
Si podrian usar un PIC como eso, pero para que complicar el silicio ?

[DominusDRR]

Saludos. En alguna parte leí que el MTCH112 es en realidad un PIC, y como tal, tiene bugs en el firmware, posiblemente debas actualizar el firmware interno. Lo mejor sería levantar un ticket técnico en MCHP.

No se donde habras leido eso pero. Es tan absurdo como suena. Mas que firmware, de silicio cuando el integrado no posee un firmware programable.
Si podrian usar un PIC como eso, pero para que complicar el silicio ?

Me equivocado con el MTCH6301

... the chip is actually one of their microcontrollers so, if your PCB has the programming lines connected to it, then you can use your PICKIT to reprogramme it...

https://www.reddit.com/r/AskElectronics/comments/1p4pg8/has_anyone_here_used_the_mtch6301/?

No me sorprendería si el MTCH112 también fuese un PIC.

[KILLERJC]

Me basto con leer un poquito y encontrar a lo que se refiere y ver que exactamente que esta diciendo.

• el datasheet no muestra ninguna FLASH como para tener un firmware, tiene memoria como para configurarlo como cualquier otro registro, la unica coneccion saliente/entrante es la de I2C.
• fui a buscar el firmware, ya que es obligacion de ellos entregartelo asi como todas sus versiones, esto es mas que obvio, de que te sirve algo si no tenes el firmware?. No existe. peeero aparece esto: PICkit Serial Analyzer Firmware for MTCH6301 PCAP support
  
  Solo fue necesario descargarlo abrir el pdf, para leer la introduccion y notar que :
  
  

  The purpose of this document is to provide reference for the physical connection and configuration options for the Microchip Projected Capacitive PKSPCAP Communications Board. This board is a PICkitTM Serial Analyzer (PKSA) with firmware installed that converts the device to support Microchip’s MTCH6301 and other projected capacitive (PCAP) hardware.
  
  To configure the PKSA to be used to work with Microchip PCAP hardware the user must download and update the PKSA with PKSPCAP firmware.

  
  Si.. es el Pickit2 el cual se debe actualizar el firmware para poder soportar, leer e interpretar a estos dispositivos, y no el dispositivo en si.
  
  En resumen... el se expreso mal, o no lo dejo muy en claro, vos podes usar el Pickit2 para poder acceder al dispositivo y configurarlo, sin necesidad de usar un microcontrolador con I2C y usando el Pickit2, tambien imagino que podras observar la salida de ese sensor, todo esto si instalas el firmware para el Pickit2
  
  Hablando de ese ultimo que pasaste.. Las consideraciones para hacer el sensor no son nada faciles
  http://ww1.microchip.com/downloads/en/DeviceDoc/FAQs%20-%20Sensor%20Design%20Guidelines.pdf

[DominusDRR]

Bueno, dejémoslo en el velo del misterio del porqué tiene casi la misma distribución de pines  de un PIC32MX.

[DominusDRR]

...
Hablando de ese ultimo que pasaste.. Las consideraciones para hacer el sensor no son nada faciles
http://ww1.microchip.com/downloads/en/DeviceDoc/FAQs%20-%20Sensor%20Design%20Guidelines.pdf

http://www.microchip.com/forums/m875809.aspx

[KILLERJC]

Es un PIC32 como bien decis pero no hay indicios que se pueda cargar un firmware dentro (reprogramandolo), podria haberse realizado una version resumida del mismo micro sin tener tantas cosas (que harian a un PIC32).
Supongamos por un momento que lo hacen por soft y se lleva su tiempo, tambien que es un PIC32, y que no se cambio el silicio por cuestiones economicas, etc. Es decir un PIC32 con un programa.
 
Tu secreto y es por lo que estas cobrando aparte es justamente ese firmware, y no se lo vas a enviar a nadie, sino al primero que se lo envies, se lo cargas al primer PIC32 y ya tenes tu sensor por unos 0.5 dolares menos la unidad. Entonces esa "re-programacion" es a lo que me referia. De seguro que con ayuda de algun desencriptador.

Probar Si es un PIC32 es facil, es usar los pines que se usan en la grabacion del PIC32 y probar grabar eso. Si funciona es un PIC32, si no funciona hay cambios en el silicio.

Y con respecto al firmware, si es un error mio. Tome el concepto de firmware como algo que normalmente grabas al aparato. Pero estos pueden estar en una ROM y aun asi ser llamados firmware. Asi que acepto mi equivocacion y te doy la razon

Creo que por eso, es que el usuario de reddit puso esto:

contact Microchip, and get them to send you replacement parts. This is what I did. I had to desolder the chip, and put in the replacement. Don't forget the upgraded version of PCAP!

Es decir le enviaron un PIC32 con una version mas nueva.

[DominusDRR]

Es un PIC32 como bien decis pero no hay indicios que se pueda cargar un firmware dentro (reprogramandolo), podria haberse realizado una version resumida del mismo micro sin tener tantas cosas (que harian a un PIC32).
Supongamos por un momento que lo hacen por soft y se lleva su tiempo, tambien que es un PIC32, y que no se cambio el silicio por cuestiones economicas, etc. Es decir un PIC32 con un programa.

Pueda que sea un micro con memoria OTP y por lo tanto es imposible una actualización y como vuestra merced dice, se debe comprar un dispositivo actualizado.

Tu secreto y es por lo que estas cobrando aparte es justamente ese firmware, y no se lo vas a enviar a nadie, sino al primero que se lo envies, se lo cargas al primer PIC32 y ya tenes tu sensor por unos 0.5 dolares menos la unidad. Entonces esa "re-programacion" es a lo que me referia. De seguro que con ayuda de algun desencriptador.

Es algo obvio, no tendría lógica entregar un archivo hexadecimal, nadie está discutiendo sí MCHP debe publicar dicho archivo en alguna parte.

Probar Si es un PIC32 es facil, es usar los pines que se usan en la grabacion del PIC32 y probar grabar eso. Si funciona es un PIC32, si no funciona hay cambios en el silicio.

.

Lo correcto sería que utilizaron un nucleo de un PIC32 para hacer el dispositivo, y tiene una nueva ID, me imagino que al leerlo con un PICKit, lo detectará como MTCH6301 por su ID que no corresponde a un PIC32 determinado o como un dispositivo no determinado,