veteq

Насколько я помню выход из режима standby сопровождается запуском программы сначала... Сохраняются только регистры бэкапа И да, там есть какая-то еррата насчет режима standby...

Судя по картинке, как будто-то щуп осциллографа без делителя, а значит фронты заваливаются самим щупом осциллографа. Такие сигналы лучше смотреть с делителем.

Как вариант попробовать еще в отладчике пошагать по кольцу функциям передачи по SPI , а то ощущение создается что SPI как-то не так работает вот по этим функциям пройтись отладчиком, каждый шаг и постоянно,(т.е. на каждую функцию будет уходить около секунды) будут ли всплывать нули? while(SPI_I2S_GetFlagStatus(SPI1, SPI_I2S_FLAG_BSY) == SET); SPI_I2S_SendData(SPI1, data); while(SPI_I2S_GetFlagStatus(SPI1, SPI_I2S_FLAG_BSY) == SET); return SPI_I2S_ReceiveData(SPI1);

Для начала попробовать проверить работу SPI, постоянно вычитывая WHO_AM_I - 0x0F У меня на пинах 5,6,7 подтяжка на землю стоит, и SPI SPI_CPHA_1Edge и SPI_CPOL_Low signed short value; unsigned char *valueL = (unsigned char *) (&value); unsigned char *valueH = ((unsigned char *) (&value) + 1); *valueL = SPI.CommandReceived[5]; *valueH = SPI.CommandReceived[6]; if ((value & (1 << 15)) != 0) { MEMS.Z = (value >> 4) | 0xF000; } else { MEMS.Z = value >> 4; }

Наверное косяк с L и H, я помню что они там хитро расчитываются, и вроде бы даже косяк в даташите был... Такая тема уже была на форуме Upd: там не должно быть нолей в плоскости паралелльной к земле должно быть 1g

uint16_t delay_count = 0; Попробовать добавить volatile к нему...

Надо искать с расширением С раз уж на то пошло, а не объектные файлы... Обработчик уже где-то определён в hal... Тупо воспользоваться поиском по всему проекту и найти этот обработчик.... И да: в исходнике неправильное название обработчика sys а не sis... Где-то правильно написано где-то нет...

Кстати STM32L есть в двух вариациях без буквы A в конце названия(старые) и с буквой A (новые), как я понимаю на новом тех процессе, регресс в кол-перезаписи eeprom и бекап регистрах и другая еррата. Вот в новом потребление несколько снижено по сравнению со старым, плюс памяти больше добавили. У ST есть ещё документ в котором сравниваются характеристики старых и новых.

Есть микроконтроллер STML051, надо внутри тела программы запустить внутренний загрузчик ST. В памяти есть место для записи определеного маркера по которому будет происходить сравнение при сбросе 0x200017F0. При сбросе проц прыгает в Reboot_Loader и через некоторое время ресетится... В чем может быть проблема? стартап файл: Reset_Handler /* Bootloader jumping */ ldr r0, =0x200017F0 ldr r1, =0xDEADBEEF ldr r2, [r0, #0] str r0, [r0, #0] cmp r2, r1 beq Reboot_Loader LDR R0, =SystemInit BLX R0 LDR R0, =__iar_program_start BX R0 файл загрузчика: RSEG CODE:CODE(2) THUMB PUBLIC Reboot_Loader Reboot_Loader LDR R0, =0x40021034 ; RCC_APB2ENR (+0x34) LDR R1, =0x00000001 ; ENABLE SYSCFG CLOCK STR R1, [R0, #0] LDR R0, =0x40010000 ; SYSCFG_CFGR1 (+0x00) LDR R1, =0x00000001 ; MAP ROM AT ZERO STR R1, [R0, #0] LDR R0, =0x1FF00000 ; ROM BASE (STM32L051) LDR R1, [R0, #0] ; SP @ +0 MOV SP, R1 LDR R0, [R0, #4] ; PC @ +4 BX R0 END

Есть проблема со входом в бутлоадер STM32L051 (cortex m0+) из тела программы, микроконтроллер сбрасывается. Тот же код только с другими адресами прекрасно работает на STM32L151 и STM32L401 (cortex m3/m4). Подскажите в чем может быть проблема? void (*SysMemBootJump)(void); SysMemBootJump = (void (*)(void)) (*((unsigned int*) 0x1FF00004)); __disable_irq(); SysTick->CTRL = 0; SysTick->LOAD = 0; SysTick->VAL = 0; __set_MSP(0x20001000); SysMemBootJump();

Возможно ли прервать работу vTaskDelay, т.е. разблокировать задачу досрочно? vTaskResume может с этим помочь? Например выйти из этой функции досрочно.: vTaskDelay(1000 / portTICK_PERIOD_MS);

У NXP нужно дергать также аналог ножки BOOT, которая дергается вместе с ресетом (с помощью DTR и RTS), для перевода МК в режим UART bootloader. Аналог STM Flash Loader Demo, есть GUI и командная строка и даже исходники.

Есть проблема с запуском J-LINK (китайский V8) отладчика с STM32F401RB, при попытке отладить возникает ошибка Found SWD-DP with ID 0x... Fatal error: Session aborted! В J-LINK Commander ядро не индицирует но пишет что Found SWD-DP with ID 0x... После нескольких попыток может показать еще несколько разных ошибок... после этих действий не могу уже ничего сделать с камнем через STMFlashLoader, ни стереть ни записать.... вернее пишет что стирает, но ничего записать не может, или записывает но проверить не может.... в общем ничего не работает. Также есть другой J-Link (оригинал железо v6, перешит на v7) с ним отладка происходит нормально все шьет и читает, если не запороть отладчиком камень отладчиком V8 выше. Помогает только в J-Flash залочить камень, потом разлочить, после этого все нормально работает. При всем при этом J-LINK V8 отлично работает с STM32L151CB, и др контроллерами от NXP. Не работает только с этим камнем... Подскажите в чем может быть проблема?

Нет, не пробовал, т.к. этот вариант не подходит.

Подключил MSP430F2132 и STM32 по SPI. STM32 как master, и MSP как slave соответственно использую 3-wire. MSP430 принимает байты корректно, а вот отсылает уже непонятно что. Частота SPI 31250 ГЦ. Частота MSP 16 Мгц. Например UCA0TXBUF=1 в ответ 128, UCA0TXBUF=2 в ответ 1, UCA0TXBUF=3 в ответ 129, UCA0TXBUF=4 в ответ 2, UCA0TXBUF=255 в ответ 255 Эти ответы соответствуют картине на осциллографе, т.е. STM32 принимает корректно. Вопрос где я делаю не так? void InitSPI() { P3SEL |= 0x31; UCA0CTL1 = UCSWRST; // **Put state machine in reset** UCA0CTL0 |= UCCKPL+UCMSB + UCMODE_0 + UCSYNC; UCA0CTL1 &= ~UCSWRST; // **Initialize USCI state machine** IE2 |= UCA0RXIE; // Enable USCI0 RX interrupt } #pragma vector=USCIAB0RX_VECTOR __interrupt void USCIA0RX_ISR(void) { unsigned char buffer; buffer=UCA0RXBUF; UCA0TXBUF=0x1; }