[Danis 0]

На той неделе "морозили" изделие на основе STM32F1xx.

При температуре ниже минус 65 работало без проблем (ниже не получалось).

Если нужны подробности, можно их развить.

 

Я тоже морозил F100 серию, но нет такого холодильника, чтоб до – 60, довольствовался уличными -30. Все ОК работало. А нагревать не пробывали, как там со стабильностью?

[adnega 10]

Я тоже морозил F100 серию, но нет такого холодильника, чтоб до – 60, довольствовался уличными -30. Все ОК работало. А нагревать не пробывали, как там со стабильностью?

 

Греть проще. До +85 и выше точно грел, но не на прогоне.

Кстати, встроенный датчик температуры (и внутренняя опора) очень даже ничего)

[acvarif 0]

Возникла проблема:

Отладочная плата STARTERKIT SK-STM32F217.

Программатор JetLink8/Ultra, драйвер 4.40d.

Среда разработки: Keil 4.23.

Поскольку JetLink8 от Starterkit это не настоящий SEGGER то появление проблемы вполне возможно.

У меня наблюдались частые, на мой взгляд опасные для Flash, сбои JetLink8 на драйвере 4.40d. До таких художеств как у Вас не дошло. Я возвратился на драйвер 4.22f.

Советую перейти на драйвер 4.22f. Работает гораздо надежнее. С загрузкой и отладкой сбои довольно редки. Единственная проблема часто приходится реконектится к USB - Комп теряет отладчик. Подозреваю, что это связано с недостатком питания по USB от конкретного ПК. Проверю на других ПК тогда точно можно сказать.

Изменено 6 февраля, 2012 пользователем Acvarif

[dezna 0]

Поскольку JetLink8 от Starterkit это не настоящий SEGGER то появление проблемы вполне возможно.

У меня наблюдались частые, на мой взгляд опасные для Flash, сбои JetLink8 на драйвере 4.40d. До таких художеств как у Вас не дошло. Я возвратился на драйвер 4.22f.

Советую перейти на драйвер 4.22f. Работает гораздо надежнее. С загрузкой и отладкой сбои довольно редки. Единственная проблема часто приходится реконектится к USB - Комп теряет отладчик. Подозреваю, что это связано с недостатком питания по USB от конкретного ПК. Проверю на других ПК тогда точно можно сказать.

скорее всего дело не в ПК а вкабеле USB. у меня такая проблема была с ft2232. кабель USB брал от принтера 3м. так сопротивление 1 жилы там 7Ом, а сама 2232 потребляет от 30мА. на ровном месте падение напряжения 0,42В. а если ещё и питать устройство от программатора, то отваливался программатор практически при каждой прошивке.

перепаял кабель и стало мне счастье! попробуйте - может такая же проблема.

кабель я взял 2 витые пары в общем экране.

[Angle 0]

Привет всем.

У меня такой вопрос по IAP.

На STM32F103RBT6 было написано приложение с функциями IAP (сохранял редко изменяемы настройки устройства - в конец внутренней флеш-памяти).

Далее был написан загрузчик для обновления прошивки на основе AN2557 - STM32F10x IAP using the USART, все отлично работает, пепрошивает область флеш с адреса 0x8003000.

Стартует основная программа из загрузчика - переходим на адрес 0x8003000 через присвоение этого адреса указателю на функцию, с последующим вызовом этой функции+переинициализации стека.

Это работает, но! в основном приложении перестали работать функции IAP(сохранение данных в конец флеши) - контроллер зависает.

В чем может быть дело?

[dezna 0]

скорее всего страница flash, на которой находятся данные, пересекается со страницей flash памяти программ.

при сохранении настроек необходимо стереть страницу (0.5, 1 или 2 кБ в зависимости от кристала).

и если на этой странице есть код исполняемой программы, то она теряется.

читать страницу в буфер, а затем перезаписывать, тоже не вариант.

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

счетчика команд, или HARDFAULT. это не тестировал, потому не могу сказать.

самый простой способ прочитать программу и сравнить с образом. (верифицировать)

Изменено 7 февраля, 2012 пользователем IgorKossak
Бездумное цитирование

[Angle 0]

Страницы flash не пересекались, это я проверял.

Оказалось нужно было включить HSI в программе стартующей с адреса 0x8003000, и IAP заработал. (Рекомендации взял с PM0042 STM32F10xxx Flash programming)

Однако, если эту программу зашить с нулевого адреса flash, вместо бутлоадера, IAP работает и без HSI (!?)

Изменено 8 февраля, 2012 пользователем Angle

[ReRayne 0]

wedmeed, начинает с файла стартапа и переходит в main. Похоже, у меня действительно SWD плохо работал в отладчике.

Acvarif, огромное спасибо, помогло! (у меня на 4.22f другой глюк, слетает прошивка с программатора).

dezna, спасибо, буду знать на будущее. Правда, не мой случай, кабели короткие и с питанием все ок.

 

Очередной неведомой косяк моих кривых ручонок.

Toolchain: MDK-ARM Standard Version: 4.21

Middleware: RL-ARM Real-Time Library Version V4.13

Toolchain Path: BIN40\

C Compiler: Armcc.Exe V4.1.0.713

Assembler: Armasm.Exe V4.1.0.713

Linker/Locator: ArmLink.Exe V4.1.0.713

Librarian: ArmAr.Exe V4.1.0.713

Hex Converter: FromElf.Exe V4.1.0.713

CPU DLL: SARMCM3.DLL V4.21

Dialog DLL: DARMSTM.DLL V1.62

Target DLL: Segger\JL2CM3.dll V2.5

Dialog DLL: TARMSTM.DLL V1.60

 

В файле stm32_eval_sdio_sd.h разкоменчен дефайн: #define SD_DMA_MODE ((uint32_t)0x00000000)

Есть файл diskio.c, в котором описываются функции работы с SD для файловой системы:

#include "stm32_eval_sdio_sd.h"
/**************************/
/*-----------------------------------------------------------------------*/
/* Read Sector(s)														*/
DRESULT disk_read (
			   BYTE drv,		/* Physical drive nmuber (0..) */
			   BYTE *buff,		/* Data buffer to store read data */
			   DWORD sector,	/* Sector address (LBA) */
			   BYTE count		/* Number of sectors to read (1..255) */
				 )
{
 switch (drv) 
 {
case SDIO_DRIVE:
{	 
  Status = SD_OK;

#if defined SD_DMA_MODE 	/* DMA Transfer */
	/* Read Multiple Blocks */
	Status = SD_ReadMultiBlocks((uint8_t*)(buff),(sector)*SECTOR_SIZE,SECTOR_SIZE,count);

	/* Check if the Transfer is finished */
	Status = SD_WaitReadOperation();

	/* Wait until end of DMA transfer */
	while(SD_GetStatus() != SD_TRANSFER_OK);
#else  /* Polling Transfer */
	for (int secNum = 0; (secNum < count) && (Status == SD_OK); secNum++)
	{
		Status = SD_ReadBlock((buff+SECTOR_SIZE*secNum),
							  (sector+secNum)*SECTOR_SIZE, 
							  SECTOR_SIZE);

		while(SD_GetStatus() != SD_TRANSFER_OK);
	}
#endif

	if (Status == SD_OK)	return RES_OK;
	else					return RES_ERROR;
}

 }
 return RES_PARERR;
}

Внезапно оказывается, что компилятор мне включает код не в блоке #if defined SD_DMA_MODE, а блок #else.

Изменено 8 февраля, 2012 пользователем IgorKossak
[codebox]

[demiurg_spb 0]

Внезапно оказывается, что компилятор мне включает код не в блоке #if defined SD_DMA_MODE, а блок #else.

ИМХО синтаксис препроцессора таков:

#ifdef SD_DMA_MODE 
//или
#if defined(SD_DMA_MODE)

хотя попробовал в Кейле и

#if defined SD_DMA_MODE

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

[Penchev 0]

Помогите разобратся с SPI.Захотел подключить к STM32VLDISCOVERY дисалей LS020,настроил порт и SPI ,в симуляторе KEIL'a v4.23 работает нормально,а именно после записи в SPI1->DR= Cmd; сбрасывается флаг TXE и дальше ждем пока он не подымится while(!((SPI1->SR)&SPI_SR_TXE)); .После того как поднялся идет отправка следующего байта.

привожу настройку SPI и функцию отправки байта.

//*********************Конфигурация SPI в мастер - режиме**********************************************
  
// SPI1->CR1 |= SPI_CR1_BR_0;        // Частота передачи Fclck/4
  SPI1->CR1 |= SPI_CR1_DFF;            // Размер кадра - 16 бит
  SPI1->CR1 |= SPI_CR1_MSTR;        // Установка мастер - режим
  SPI1->CR1 |= SPI_CR1_BIDIMODE;    // Тип коммуникации в 1 направлении                                    
  SPI1->CR1 |= SPI_CR1_BIDIOE;        // Только передача
  SPI1->CR1 |= SPI_CR1_SSI;            //    без этого 
  SPI1->CR1 |= SPI_CR1_SSM;            //    и этого в мастер режимме не работает

  SPI1->CR1 |= SPI_CR1_SPE;          // Включение SPI


// Запись команды в дисплей
void Lcd_Write_Command(short Cmd){
  
  GPIOA->BSRR |= RS;                    //RS установлить в 1 (команда)
  GPIOA->BRR |= CS;                       //CS установить в 0 (активный дисплей)
  SPI1->DR = Cmd;                       // ПОСЛЕ ЗАПИСИ В SPI1->DR БИТ TXE НЕ СБРАСЫВАЕТСЯ
  while(!((SPI1->SR)&SPI_SR_TXE));       // ПОЭТОМУ ИДЕТ СРАЗУ ЖЕ ЗАПИСЬ СЛЕДУЮЩЕГО БИТА.
  GPIOA->BSRR |= CS;                     //CS установить в 1 (неактивный дисплей)
}

 

Подключил железо залил программу и дисплей не инициализируется,при пошаговой отладки заметил, что флаг TXE не сбрасывается после записи в SPI1_DR затем идет проверка бита TXE он постоянно поднят и происходит отправка следующего байта,а буфер то не пуст.....

 

Добавив задержку в функцию отправки байта

// Запись команды в дисплей
void Lcd_Write_Command(short Cmd){
  int nCount =  15;
  GPIOA->BSRR |= RS;                    //RS установлить в 1 (команда)
  GPIOA->BRR |= CS;                       //CS установить в 0 (активный дисплей)
  SPI1->DR = Cmd;                
  while(!((SPI1->SR)&SPI_SR_TXE));
  
  for (; nCount != 0; nCount--);
  GPIOA->BSRR |= CS;                     //CS установить в 1 (неактивный дисплей)
}

 

Все заработало.Может ли кто нибудь проверить мой код у себя в железе и посмотреть,что творится с этим флагом TXE.

Или дать рабочий кусочек кода с SPI?

LS020.rar

[ChipKiller 0]

привожу настройку SPI и функцию отправки байта.

... странно, что в настройках не видно строчки

RCC->APB2ENR= .....

[Penchev 0]

Да не все показал,повторяюсь все работает,только не так как надо.Флаг TXE в железе не сбрасывается.

//**************************** Настройка POTA **********************************************************
  RCC->APB2ENR|= RCC_APB2ENR_IOPAEN; // Разрешить тактирование порта A.
//  RCC->APB2ENR|= RCC_APB2ENR_AFIOEN; // Тактирование альтернативных функций GPIO.
  RCC->APB2ENR|= RCC_APB2ENR_SPI1EN; // Включение тактирования SPI1.
  GPIOA->CRL |= GPIO_CRL_MODE2;         // Output MODE 50 MHz
  GPIOA->CRL &=~GPIO_CRL_CNF2;          // Вывод  PA.2 - на выход (RST).
  GPIOA->CRL |= GPIO_CRL_MODE3;         // Output MODE 50 MHz
  GPIOA->CRL &=~GPIO_CRL_CNF3;          // Вывод  PA.3 - на выход (RS).
  GPIOA->CRL |= GPIO_CRL_MODE4;         // Output MODE 50 MHz
  GPIOA->CRL &=~GPIO_CRL_CNF4;          // Вывод  PA.4 - на выход (NSS).
  GPIOA->CRL |= GPIO_CRL_MODE5;        // Output MODE 50 MHz
  GPIOA->CRL &=~GPIO_CRL_CNF5;
  GPIOA->CRL |= GPIO_CRL_CNF5_1;     // Вывод  PA.5 на выход как альтернативная функция (SCK).
  GPIOA->CRL |= GPIO_CRL_MODE6;        // Output MODE 50 MHz
  GPIOA->CRL &=~GPIO_CRL_CNF6;
  GPIOA->CRL |= GPIO_CRL_CNF6_1;     // Вывод  PA.5 на выход как альтернативная функция (SCK).
  GPIOA->CRL |= GPIO_CRL_MODE7;        // Output MODE 50 MHz
  GPIOA->CRL &=~GPIO_CRL_CNF7;
  GPIOA->CRL |= GPIO_CRL_CNF7_1;     // Вывод  PA.7 на выход как альтернативная функция (MOSI)

Изменено 10 февраля, 2012 пользователем Penchev

[dezna 0]

Помогите разобратся с SPI.

 

 

SPI1->CR1 |= SPI_CR1_SSI; // без этого

SPI1->CR1 |= SPI_CR1_SSM; // и этого в мастер режимме не работает

 

использование SS сигнала в MASTER описано в rm0008 "25.3.3 Configuring the SPI in master mode" п.5,

а также в п.6 написано:

6. The MSTR and SPE bits must be set (they remain set only if the NSS pin is connected

to a high-level signal).

 

 

[Penchev 0]

SPI1->CR1 |= SPI_CR1_SSI; // без этого

SPI1->CR1 |= SPI_CR1_SSM; // и этого в мастер режимме не работает

 

использование SS сигнала в MASTER описано в rm0008 "25.3.3 Configuring the SPI in master mode" п.5,

а также в п.6 написано:

6. The MSTR and SPE bits must be set (they remain set only if the NSS pin is connected

to a high-level signal).

 

Спасибо за наводку,но с этими битами я попробую разобратся если понадобится аппаратно NSS дергать,а пока я это делаю софтово.

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

[Сергей Борщ 119]

затем идет проверка бита TXE он постоянно поднят и происходит отправка следующего байта,а буфер то не пуст.....

А вы не допускаете, что между записью в SPI1->DR и чтением отладчиком содержимого SPI1->SR проходит некоторе время, за которое байт успевает уйти из буфера и буфер таки оказывается действительно пуст?

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

 

А ошибка у вас в другом месте: обратите внимание на картинку со структурой модуля SPI. Там четко видно два регистра: Tx buffer и Shift register. Так вот, TXE указывает на то, что ваш байт ушел из Tx_buffer в shift register, но это совершенно не означает, что байт уже выдвинулся. Вам надо проверять RXNE, именно он показывает, что новый байт пришел. А приходит байт одновременно с отправкой. И не забывайте очищать его фиктивным чтением SPI1->DR после проверки.

 

Добавлено:

И, кстати, поскольку при входе в функцию у вас передача не велась - у вас пусты и Txbuffer и Shift Register. Поэтому при записи в DR ваш байт попадает в Tx Buffer и сразу же проваливается в Shift Register. Согласно картинкам в даташите TXE будет выставлен на время одного бита. Это доказывает, что симулятор ваш отрабатывает периферию с ошибкой. И осциллографом на ноге вы можете ничего не увидеть, если скорость обмена по SPI достаточно велика.