РЕ-мулятор - внутрисхемный эмулятор 1801РЕ2/1801РР1

[Sergei Frolov]

[QUOTE=Vslav;783647]

// Как оказалось если в качестве сигнала CS используется выход
// с микросхем 1801ВП1 (в частности -037) то к моменту ниспадающего
// SYNC матрица еще не успевает декодировать адрес и РЕ-мулятор
// не получает устойчивой комбинации сигналов на входе. Поэтому
// выполняем ожидание
//
@@WaitSel:      ldr     R4, [R2, #PIO_IDR]                      // загружаем управляющие
                movs    R0, R4, lsr #(SYNC_BIT+1)               // сигналы и проверяем
                bcs.n   @@SyncFall                              // сигнал SYNC
                movs    R0, R4, lsr #(DIN_BIT+1)                // проверим активность
                bcs.n   @@WaitSel                               // сигнала DIN
                ubfx    R0, R4, #SEL1_BIT, #6                   //
                ldr     R3, [R6, R0, lsl #2]                    //
                tst     R3, R3                                  // при данной комбинации
                beq.n   @@WaitSel                               // нет доступа к ROM

Хотел бы поинтересоваться. В диаграмме адрес снимается с шины где-то одновременно с опусканием DIN, а здесь DIN ожидается и только после этого считывается адрес. В реальной системе адрес еще какое-то время висит на шине?

[Sergei Frolov]

Посмотрел, в какой момент снимается адрес (внизу) относительно DIN (вверху)

[Vslav]

Хотел бы поинтересоваться. В диаграмме адрес снимается с шины где-то одновременно с опусканием DIN, а здесь DIN ожидается и только после этого считывается адрес. В реальной системе адрес еще какое-то время висит на шине?

Нет, адрес защелкивается немножко раньше, точно по ниспадающему SYNC:

//
// Теперь ожидаем низкий уровень SYNC (ниспадающий фронт)
//
@@SyncFall:     ldr     R7, [R1, #PIO_IDR]                      // R7 предполагаемый адрес
                ldr     R4, [R2, #PIO_IDR]                      // для предварительной фиксации
                movs    R0, R4, lsr #(SYNC_BIT+1)               //
                bcs.n   @@SyncFall                              //

А Вашем фрагменте ожидается устойчивая комбинация DIN и CS.

[Sergei Frolov]

Ясно, спасибо.

[roma]

Можно ли запрограммировать начальный загрузчик через St-Link и SWD интерфейс?
Не могли бы выложить файл загрузчика для St-Link Utility.
Просто подключил ремулятор через St-Link и SWD интерфейс, чип видит, информация о чипе выводится.
Но при попытке запрограммировать a205_gcc10_jtag.hex или b205.hex пишет ошибка записи.
Видимо эти файлы либо не подходят для St-Link Utility, либо программтор пытается записать по неверным адресам.
Хотя erase чипа и проверка на чистоту проходят без ошибок ...

- - - Добавлено - - -

Как я понял нужно запрограммировать файл b205.hex с адреса 0x08000000?
Но при открытии этого файла St-Link Utility пытается его записать с адреса 0x00000000.
Как указать St-Link Utility что нужно программировать с адреса 0x08000000?
Возможно есть альтернативный тул для St-Link программатора, в котором можно выбирать начальный адрес?

[Vslav]

Можно ли запрограммировать начальный загрузчик через St-Link и SWD интерфейс?

Конечно можно, в РЕ-муляторе обычный stm32f205/207, все стандартные инструменты должны работать.

Как я понял нужно запрограммировать файл b205.hex с адреса 0x08000000?
Но при открытии этого файла St-Link Utility пытается его записать с адреса 0x00000000.

Тут надо просто переместить hex-файл на нужный адрес, например, утилитой srec_cat:
srec_cat b205.hex -Intel -offset 0x8000000 -o b205_800.hex -Intel

Получившийся b205_800.hex - точно такой же, просто начальный адрес будет 0x8000000.
Естественно, скомпилировано все правильно, прошивка и должна размещаться по такому адресу.

[Vslav]

Наконец дошли руки выложить проект на гитхаб: https://github.com/1801BM1/remul

[svinka]

Наконец дошли руки выложить проект на гитхаб: https://github.com/1801BM1/remul

Вместо кириллицы - кракозябры

[gid]

кракозябры

Не подтверждаю, у меня всё нормально, как через браузер, так и в клонированной репке. Несмотря на то, что в разных файлах проекта разные кодировки используются.

То ли гитхаб научился кодировкам, то ли Vslav знает какие-то секреты. Потому что раньше в некоторых проектах я таки видел кракозябры вместо русских букв, особенно если utf-8 было, тогда кракозябров в 2 раза больше получалось.

[Vslav]

Вместо кириллицы - кракозябры

Где именно кракозябры?
В readme.md быть не должны - это utf-8 файл, везде должен отображаться нормально (github рекомендует utf-8 и показывает нормально).
А в исходниках кракозябры на месте кириллических комментариев возможны, С/asm исходники я в utf-8 переводить не буду, останется в CP1251.