3.3 Загрузка EEPROM
А вот эта операция реально опасна для коллекции частот в вашем приёмнике – не применяйте её, по крайней мере пока не найден способ эмуляции «внешнего» EERPOM или ещё какой способ сохранить резервную копию. А дорогая «редакция» в очередной раз умывает руки.
Согласно
http://www.davidmoisan.org/radio/sangean/909memory.html для того, чтобы зарузить данные в EEPROM вашего приёмника нужно:
1. Перейти на диапазон LW;
2. Одновременно нажать кнопки LW и Light (подсветка);
3. На дисплее приемника появится надпись: DATA IN;
4. В течение двух секунд вы должны нажать кнопку Enter (ввод);
5. Через некоторое время на дисплее последовательно появятся надписи VERIFY, OK, ROM DUMP, VERIFY, ROM OK;
К сожалению сопоставить надписи с траффиком на i2c шине в этом случае значительно сложнее, но некоторые догадки можно сделать. Хотя впрочем это и не так важно.
Итак, после нажатия Enter, DATA IN процесс начинается чтением страниц памяти с «внешнего» EEPROM с адресов, 0x5800, 0x5900, .., 0x5F00 и записью их соответственно по адресам 0x5000, 0x5100, .., 0x5700 в EEPROM приёмника. Как я уже описал выше, в моем случае при чтении с «внешнего» EEPROM полученные данные представляют из себя байты со значением 0xFF. Таким образом в результате такой операции EEPROM радиоприемника оказывается зачищен и все данные с него утеряны безвозвратно.
Затем производится проверка, аналогичная уже описанному в предыдущем разделе этапу VERIFY и, поскольку на «внешнем» EEPROM и на EEPROM приёмника всё заполнено байтами 0xFF – то и процедура завершается сообщением OK.
После этого по адресу 0x57F0 (EEPROM приёмника) читается 12 байт – то, что мы в разделе 2.6 назвали идентификатором приемника. Читается два раза. В обоих случаях там байты 0xFF. Вероятно, контроллер наконец понимает, что данные ЕЕПРОМ либо некорректны, либо EEPROM пуста и перезаписывает все 8 страниц информацией по умолчанию, очевидно хранящейся где-то в его (микроконтроллера) памяти. Полагаю это и есть операция идентифицируемая как ROM DUMP.
Затем следует очередная верификация (VERIFY) – данные из EEPROM вновь читаются постранично и, судя по всему, сравниваются с копией из микроконтроллера – поскольку трассировщик дает информацию лишь о чтении по адресам с 0x5000 по 0x5700. Проверка завершается сообщением ROM OK.
3.4 Что-же делал ATS909 Programmer?
Опираясь на вышеприведенную реконструкцию можно с большой долей уверенности утверждать, что аппаратный комплекс ATS909 Programmer от Томаса Рамиреса играл роль «внешнего» EEPROM на 2048 байт с базовым адресом 0x5800. И задачу воссоздания его на современной аппаратной базе можно формализовать как «реализацию I2C Slave устройства с EEPROM-подобным интерфейсом ёмкостью 2048 байт с возможностью чтения и модификации этой памяти с ПК.» К сему предполагается ПО с возможностью считать блок данных EEPROM, изменить сообразно вкусам пользователя и записать его обратно в устройство.
4. Эксперименты в режиме I2C Master
Кроме варианта эмуляции «внешнего» EEPROM сам собой напрашивается способ непосредственной работы с чипом памяти по интерфейсу I2C. В этом случае внешнее устройство должно выступать в режиме Master. I2C трассировщик, который я использовал в своих экспериментах имеет некоторые рудиментарные возможности по управлению устройствами в режиме мастера. Попробовал и я почитать EEPROM непосредственным к нему обращением. К сожалению дальше посылки байта адреса устройства дело не пошло - мой мастер не получал требуемого подтверждения (ACK) от чипа EEPROM как будто на шине его нет. Ни подбор частоты и напряжения, ни закорачивание резисторов R373, R374 к успеху не привели – чип упорно не желает общаться с моим мастером. Я, впрочем, надеюсь что виной всему особенности генерации сигналов i2c трассировщиком и с другим железом взаимодействие станет возможным. Время покажет.
Тут самое время вспомнить о той странности, о которой я обещал рассказать описывая процесс выгрузки дампа EEPROM в разделе 3.2. Дело в том, что согласно спецификации I2C каждый переданный байт должен быть подтверждён приемником (ACK) – путём удержания последним линии SDA на низком уровне в течение девятого такта SCL. И вот при записи данных по адресам «внешнего» EEPROM (0x5800 – 0x5FFF) всё выглядело так, что линия SDA оставалась в низком состоянии в этом случае – как будто устройство и на самом деле дает подтверждение. Но такового устройства в моём случае не было. Отсюда я склонен сделать вывод, что этот псевдо-ACK есть результат работы самого контроллера который в логе трассировщика выглядит как нормальное здоровое подтверждение (ACK).
Таким образом вопрос возможности непосредственной работы с EEPROM в режиме мастера остается открытым.
Окончание следует ... 
