|
|
  |
Непонятки с конфигурацией Циклона |
|
|
|
Jun 28 2014, 20:33
|
Профессионал
    
Группа: Свой
Сообщений: 1 404
Регистрация: 11-03-11
Из: Минск, Беларусь
Пользователь №: 63 539

|
Цитата(okela @ Jun 27 2014, 14:48)  Смотрел с помощью TopJTAG Probe. С Universal Scan пока не разобрался как читать состояние пинов. Там же всё просто, лампочку на порт вешаете, если горит, значит подтянут к 1, если нет - к 0. А можно клок на порт выдать. Сам не так давно ею пользовался, плисина перестала грузиться после допайки парочки компонентов на плату, оказалось одно починили второе сломали, один из MSEL отвалился после таких манипуляций. Что накопали при помощи TopJTAG Probe? Цитата(okela @ Jun 27 2014, 14:48)  Также пробовал установить на входах MSEL[4..0] комбинацию 10011, соответствующую режиму AS. Никакой разницы - на CONF_DONE и nSTATUS все по прежнему (голый "0")... Вот тут получается, что что-то не так, должно было бы циклически пробовать слить прошивку, и nSTATUS должен был бы периодически меняться с 0 на 1 (ну и ноги AS посмотреть, если есть возможность). Попробуйте всё же проверить питание, всё ли там нормально, как писал, у нас проблема была именно в этом.
|
|
|
|
|
Jun 30 2014, 12:30
|
Профессионал
    
Группа: Свой
Сообщений: 1 404
Регистрация: 11-03-11
Из: Минск, Беларусь
Пользователь №: 63 539

|
Цитата(okela @ Jun 30 2014, 14:24)  Покурив доки нашел такую зацепку: сигнал nSTATUS мониторится на стадии POR и если что-то с питающими напругами не так, то он не поднимется в исходную "1". Также обратил внимание на то, что рекомендуется последовательность подачи питания на кристалл: VCC_1.1V --> VCC_2.5V, VCC_3.3V. Я последний момент упустил при разработке схемы. У меня все преобразователи запускаются одновременно. Возможно из-за этого сигнал nSTATUS не устанaвливается в исходное состояние ? Вполне возможно, на наших платах так и сделано, источники запускаются последовательно, сначала подаётся 1.1 В на ядро, потом уже питание на банки. Сигнал Power Good источника 1.1 В разрешает запуск остальных. Запитайте от внешнего источника питания, проверите - в этом ли причина.
|
|
|
|
|
Jul 2 2014, 19:00
|
Частый гость
 
Группа: Свой
Сообщений: 165
Регистрация: 11-01-05
Из: Украина, г. Одесса
Пользователь №: 1 896

|
Цитата(doom13 @ Jun 30 2014, 15:30)  Вполне возможно, на наших платах так и сделано, источники запускаются последовательно, сначала подаётся 1.1 В на ядро, потом уже питание на банки. Сигнал Power Good источника 1.1 В разрешает запуск остальных. Запитайте от внешнего источника питания, проверите - в этом ли причина. Попробовал подавать напруги 2,5 В и 3,3 В после запуска источника 1,1 В. Сигнал nSTATUS попрежнему сидит в нуле сразу после включения всех напряжений ... Цитата(Raven @ Jul 2 2014, 19:23)  Если мне не изменяет память, nSTATUS также может сбрасываться при ошибке в принимаемом битовом потоке. Есть ли у вас возможность провести конфигурирование на существенно более низкой частоте TCK? Скажем, вытащить из дальнего ящика ByteBlaster и попробовать с ним?
К сожалению, классический USB Blaster (тот, что первого поколения) не позволяет снижать fTCK, и это при том, что штатно она задрана высоковато (6 МГц). nSTATUS изначально притянут к нулю и не дрыгается в процессе. С ByteBlaster-ом несколько проблематично все - ввиду LPT-порта. Но судя по всему дело не в частоте JTAGa. т.к. сам он вполне нормально работает как я писал выше.
|
|
|
|
|
Jul 2 2014, 19:17
|
Профессионал
    
Группа: Свой
Сообщений: 1 404
Регистрация: 11-03-11
Из: Минск, Беларусь
Пользователь №: 63 539

|
Ещё раз глянул на схему конфигурации FPP (у Вас всё, как на рисунке?), и возник вопрос: не может ли MAX II быть причиной данной проблемы? И кстати, уже советовали: Цитата(jks @ Jun 25 2014, 12:19)  Если MAXII и FPGA в одной цепочке и nCONFIG заведен на MAXII то его надо отвязать от него или отключить питание ядра MAXII. Это Вы проверяли?
Эскизы прикрепленных изображений
|
|
|
|
|
Jul 3 2014, 20:39
|
Частый гость
 
Группа: Свой
Сообщений: 165
Регистрация: 11-01-05
Из: Украина, г. Одесса
Пользователь №: 1 896

|
Цитата(doom13 @ Jul 2 2014, 23:17)  По схеме конфигурации nCONFIG подтянут к плюсу, не может ли то, к чему он у Вас подключен каким-то образом вешать его в ноль, что подтяжка к 1 не работает и на нём всегда 0? Сигнал nCONFIG подтянут к "1" пока постоянно и никто его не дергает.
|
|
|
|
|
Jul 4 2014, 07:53
|
Частый гость
 
Группа: Свой
Сообщений: 165
Регистрация: 11-01-05
Из: Украина, г. Одесса
Пользователь №: 1 896

|
Цитата(doom13 @ Jul 4 2014, 01:18)  Согласно схеме FPP он ещё и на MAX II идёт, или у Вас как-то по-другому? Нет - MAX II у меня для других целей используется, а схема загрузки в режиме FPP будет через дополнительный контроллер.
|
|
|
|
|
Jul 4 2014, 09:15
|
Местный
  
Группа: Свой
Сообщений: 249
Регистрация: 3-04-11
Из: .
Пользователь №: 64 084

|
Надо в отладчике JTAG попробовать выдать команду PULSE_NCONFIG = 10'b00_0000_0001 и посмотреть на реакцию nSTATUS. Если nSTATUS не поднимается в "1", то тут вариантов несколько: - резистор подтяжки не подключен к ноге - нет нужного напряжения - кто-то извне удерживает в 0 - пробит нижний транзистор I/O буффера (это можно проверить тестером). Какой кстати чип у Вас?. Если поможет я из Quartusa вычитывал состояние пинов таким образом. Надо будет заменить индексы нужных Вам выводов и длину BSR регистра из BSD файла для Вашего чипа. Сначала выполнить scan_jtag_chain для инициализации и поиска устройств. потом sample_io для вывода состояния пинов. CODE set usbblaster_name "" set test_device ""
proc scan_jtag_chain {} { global usbblaster_name global test_device # List all available programming hardware, and select the USB-Blaster. # (Note: this example assumes only one USB-Blaster is connected.) puts "Programming Hardware:" foreach hardware_name [get_hardware_names] { puts $hardware_name if { [string match "USB-Blaster*" $hardware_name] } { set usbblaster_name $hardware_name } } puts "\nSelect JTAG chain connected to $usbblaster_name.\n";
# List all devices on the chain, and select the first device on the chain. puts "\nDevices on the JTAG chain:" foreach device_name [get_device_names -hardware_name $usbblaster_name] { puts $device_name if { [string match "@1*" $device_name] } { set test_device $device_name } } puts "\nSelect device: $test_device.\n";
# Open device open_device -hardware_name $usbblaster_name -device_name $test_device
# Retrieve device id code. # IDCODE instruction value is 6; The ID code is 32 bits long.
# IR and DR shift should be locked together to ensure that other applications # will not change the instruction register before the id code value is shifted # out while the instruction register is still holding the IDCODE instruction. device_lock -timeout 10000 device_ir_shift -ir_value 6 -no_captured_ir_value puts "IDCODE: 0x[device_dr_shift -length 32 -value_in_hex]" device_unlock
# Close device close_device }
proc pulse_nconfig { } { global usbblaster_name global test_device set ir_nconfig 1 # JTAG PULSE_NCONFIG command # Open device open_device -hardware_name $usbblaster_name -device_name $test_device device_lock -timeout 10000 # scan instruction device_ir_shift -ir_value $ir_nconfig -no_captured_ir_value device_unlock # Close device close_device }
# # read IO proc sample_io { } { global usbblaster_name global test_device set ir_sample 5 # JTAG sample command set bsr_length 997 # BSR length array set bsr_io { NCE 0 NCONFIG 3 DCLK 6 NCSO 9 ASDO 12 DATA0 15 NSTATUS 939 CONF_DONE 942 MSEL0 945 MSEL1 948 MSEL2 951 MSEL3 954 } # Open device open_device -hardware_name $usbblaster_name -device_name $test_device device_lock -timeout 10000 # scan instruction device_ir_shift -ir_value $ir_sample -no_captured_ir_value # scan data #puts "Capture data: [device_dr_shift -length $bsr_length -value_in_hex]" set bsr_data [ string reverse "[device_dr_shift -length $bsr_length]" ] puts "Captured data = $bsr_data\n" # dump MSEL data set MSEL0 "[string index $bsr_data $bsr_io(MSEL0) ]" set MSEL1 "[string index $bsr_data $bsr_io(MSEL1) ]" set MSEL2 "[string index $bsr_data $bsr_io(MSEL2) ]" set MSEL3 "[string index $bsr_data $bsr_io(MSEL3) ]" puts "MSEL0, MSEL1, MSEL2, MSEL3 = $MSEL0:$MSEL1:$MSEL2:$MSEL3"
# dump CONFIG data puts "nCE (D2) : [string index $bsr_data $bsr_io(NCE)]" # 0 puts "nCONFIG (H4) : [string index $bsr_data $bsr_io(NCONFIG)]" # 3 puts "DCLK (D3) : [string index $bsr_data $bsr_io(DCLK)]" # 6 puts "NCSO (J4) : [string index $bsr_data $bsr_io(NCSO)]" # 9 puts "ASDO (D1) : [string index $bsr_data $bsr_io(ASDO)]" # 12 puts "DATA0 (K4) : [string index $bsr_data $bsr_io(DATA0)]" # 15 #dump STATUS data set nSTATUS "[string index $bsr_data $bsr_io(NSTATUS)]" # 939 puts "nSTATUS = $nSTATUS" set CONF_DONE "[string index $bsr_data $bsr_io(CONF_DONE)]" # 942 puts "CONF_DONE = $CONF_DONE" device_unlock # Close device close_device }
|
|
|
|
|
  |
1 чел. читают эту тему (гостей: 1, скрытых пользователей: 0)
Пользователей: 0
|
|
|