Flash loader demonstrator ошибка no response from the target

Пробывал прошить через конфигуратор с закороченными контактами boot, не помогло не шьется. Диоды синий моргает, устройство в диспетчере оборудования появляется.
Ниже картинка обнаружил замыкание, хотя в этот порт не чего не подсоединялось ни когда.
Что могло вызвать такое?
P.S. добавил немного получше фото (извиняюсь в распоряжении только телефон, если поможет в диагностики, то смогу к другу сбегать за фотиком). Flash loader demonstrator тоже пробовал и на всех скоростях, пишет no response from the target the bootloader cannot be started.

Контроллер перестал работать, когда все провода разместил на раме, после решил подать питание на контроллер, для проверки (на столе все так и работало, без установки в раму) через IO_1, который в свою очередь запитан от приемника, а приемник от импульсного преобразователя на 5 В.

*1 Обнаружено темное пятно и характерный запах КЗ
*2 Если подать питание на контроллер от импульсного преобразователя (3 А), то там искрит

Пробовал подчистить аккуратно ножиком, на глаз КЗ там не должно быть, да откуда там ему взять если в этот порт не чего не подсоединялось.

You have to check in system bootloader address because it varies depending on MCU.
So check out this documentation from ST: in system bootloader guide from ST

As I see you are using wrong RAM address.

Part from bootloader cook book:

Moreover, there should be a trigger for entering to system bootloader. As I understand you are using software call method from your main application. This method is not reliable if BOOT pins of MCU are uncontrolled because if serial line or updating software fails you will loose main application and you will be unable to update device. Than you’ll need programmer.

So updating, overwriting software which has system bootloader call is unsafe updating method. I would suggest it only as a own usage update method.

To have safety you should control BOOT pins.
Or implement mini custom bootloader which could be triggered by button (to start main app) and before triggering that mini bootloader would stay quiet and let system bootloader update main app. Update can’t touch mini bootloader memory, this own customized bootloader should be untouched while update. But that is a suggestion.

Easer way to take control on update is to control BOOT pins.

For example:
put 3.3V or GND (depends on MCU) on BOOT pins with jumpers , set power and than device automatically will enter to system bootloader.

After update remove jumpers, and after power reset device will enter to your new update application.
That’s all.

If you do not have BOOT0, BOOT1 pins control from hardware. I strongly recommending you to check those pins control.
There is a guide from ST about BOOT pins: reference manual

Part of description from reference manual:

I am not able to get the ST Flash loader to recognize the STM32 on the MP32. I get the following error: «No response from taget, the Boot loader can not be started. Please, verify the boot mode configuration and the flash protection status …».

 Settings-Config:

A) ST Flash Loader: 115200, 8, even, (echo disabled). 

B) I am using an ftdi usb-232 converter with a 232 shifter smd at the end (http://www.sparkfun.com/products/449):

A picture of my configuration is at the bottom.

Regarding B, this seriel configuration is working when I connect to either of the usarts on the StmDiscovery board. In fact on the discovery board, with respect to usart#1, I am connecting to pins Pa9 & Pa10 (same as MP32).

I am noticing that when I press next on ST flash Loader I can see the Tx and Rx blip momentarily, and then the Rx led on the 232-ttl converter stays on slightly dim (until I press the reset button on the MP32).

When I power up the board with the «jumper» removed,  JP11-5 is High and JP11-6 is low. I am not 100% sure, but I believe JP11-6 corresponds to the Boot_0 pin on the STM32.  

I tried several different buad rates in Flash Loader, but didnt have any luck. Also, I tried all the above on my deskop (which has serial ports). I used the same level shifter at the end of the cable. In all the above I also tried switching the Rx and Tx going to the MP32 (in case I had them backworks)s. I even tried pressing the reset after powering the board up, before trying the use the Flash Loader.

The only thing I didn’t think of until now (editing post) is that on the Discovery Board I powered the 232=ttl convertor at 3.3. When connected to the MP32 it is being powered at 5. What level is the usart at?

Is there anything I overlooked?

Thanks,

JimT

I am designing a breakout board for the STM32F103RB, I have the UART1 pins out so I can use flash programming rather than JTAG, but I am having no luck with ST flash programmer it gives me different problem messages..
1) «Unrecognized device…please, reset your device then try again»
2) «No response from the target, the boot loader can not be started. Please verify the boot mode configuration and the flash protection status, Reset your device then try again»
3) «Cannot get available commands, please, try to change echo selection, reset your device then try again»

Board:
====
I have a custom made board, which I confirm is working since I have the JTAG pins out as well and was able to connect and program it using Olimex ARM-USB-OCD + Eclipse

Connection:
=======
USB to serial FT232 —> Sparkfun logic level converter (3.3v/5v) —> STM32 UART pins

Settings:
======
Boot 0 = 1
Boot 1 = 0

Things I tried:
=========
1 — Set boot 0 & boot 1 to correct setting (As above) then quickly pressing next button on flash demonstrator
2 — Power up board, run flash demonstrator, pressing next
3 — Power up board, run flash demonstrator, press reset button, pressing next

Nothing of that works, for some reason the Flash demonstrator does not want to connect to the board

Appreciate your input on this…

Вектора прерываний переносятся потому, что и бутлоадеру и основной прошивке как правило требуется работа с прерываниями, и необходимо выбирать какой код обработчика прерывания мы выполняем — код бутлоадера или код основной прошивки. Для этой цели у STMовского контроллера прерываний есть функция переноса таблицы векторов прерываний. При этом появляется возможность иметь отдельные наборы обработчиков прерываний для бутлоадера и для основной прошивки.

Конечно возможен вариант с одной таблицей векторов, и программным выбором какой обработчик использовать (устанавливаем флаг работает бутлоадер или основная прошивка, и по этому флагу делаем if в ветках которого расположены разные обработчики) — бутлоадера или основной прошивки (в зависимости от того что активно), но такой вариант замедляет реакцию системы на прерывания.

Вариант с переносом таблицы векторов удобней тем, что в памяти программ мы можем хранить несколько разных прошивок (естественно скомпилированных и линкованных для использования разных стартовых адресов), и на старте системы можем выбирать какой из прошивок отдавать управление. Сейчас как раз занимаюсь такой развлекухой)). Требуется шиться по CAN с оооочень низкой скоростью (порядок байтов в секунду), причем с огромной вероятностью разрывов на линии. При этом вероятность того, что устройство продолжит функционировать после неудачной перепрошивки, должна стремится к 100%.

У нас работают тысячи устройств имеющих загрузчик (правда на LPC). Обновление прошивки — по любому интерфейсу по рабочему протоколу, при внезапной перезагрузке ничего не слетит 100%, загрузка нового ПО может быть продолжена с точки разрыва. Сбой питания возможен в любой момент хоть при загрузке прошивки хоть при обновлении её во флеш. Никакие таблицы векторов переносить не надо — на время работы загрузчика прерывания запрещены, рабочее ПО при старте само настраивает таблицу прерываний.

ПО состоит из:

1. неизменяемой части (загрузчика) в первом секторе флеш, который прошивается изначально на заводе и при удалённой прошивке не может быть перешит;

2. собственно рабочего ПО (во флеш после загрузчика).

Вся флеш (за исключением первого сектора) делится на две половины: первая — область исполняемого рабочего ПО; вторая — область хранения нового ПО, которое надо прошить.

Рабочее ПО по любому интерфейсу (или по всем включая CAN и беспроводные) принимает прошивку по рабочему протоколу устройства среди прочего обмена данными не мешая основной работе устройства.

Приём идёт в ОЗУ (так как если шить сразу во вторую половину флеши контроллера, то надо запрещать прерывания надолго, а это помешает работе основной программы).

По завершении приёма и проверки валидности прошивки, новая прошивка переписывается во вторую половину флеш контроллера и во флеш выставляется флаг требования обновления прошивки,

после чего делается RESET процу.

Стартует загрузчик, который обнаружив флаг и проверив CRC прошивки во второй половине, перешивает прошивку из второй половины флеш в первую, далее — удаляет флаг и стартует рабочее ПО из первой

половины флеш. Если загрузчик флаг не обнаруживает — значит не надо обновлять прошивку и просто передаёт управление рабочему ПО в первую половину прошивки.

Вот такой алгоритм обеспечивает 100%-надёжное удалённое обновление прошивки в устройстве по рабочему протоколу, не боящееся неожиданных сбоев питания и с возможностью широковещательного

обновления ПО.

Если в устройстве есть внешняя энергонезависимая память (SPI-флеш к примеру), то можно обойтись без хранения принимаемой прошивки во второй половине флеш контроллера и хранить её в этой памяти.

Вероятно, можно и не переносить, но мне пока в голову не приходит, как организовать тогда взаимодействие загрузчика и основной программы.

Расположите с помощью компоновщика команду перехода на _c_int00 (точку входа в С-программу) с самого начала образа прошивки и передавайте управление на первый адрес прошивки.

Обработчики прерываний описываютсся одинаково везде.

Неправда 🙂