I am trying to use prebuilt u-boot-nor-2015.01+fslgit-r0.bin file for QorIQ P1020 which is in QorIQ SDK V1.9 PPCE500V2 IMAGE.iso(find: https://www.nxp.com/design/software/embedded-software/linux-software-and-development-tools/linux-sdk-for-qoriq-processors:SDKLINUX). However, when i use this image, i got the weird console in the picture and i can not interact with this console. Any idea what settings/failure causes to this problem?
I have checked baudrate, serial cables, parity bits, baud divisor, cpu regs, etc.
Related
I am using STM32 cubeMX for configuration and Keil for programming.
Have set onboard led pin pc13 pin as an output pin and default in push-pull mode. Set debugger to the serial wire as I am using ST-link V2 as a debugger. RCC set HSE to crystal/ceramic resonator.
and clock configuration set to default and generated project.
Now I started with a simple LED blink program. As below
HAL_GPIO_TogglePin(led_GPIO_Port,led_Pin);
HAL_Delay(1000);
build successfully with no error and uploaded and wonder my led was not blinking and shocked as I have done this before and now this is not working.
when I debugged step by step and my code was just going from two functions repeatedly.
while ((HAL_GetTick() - tickstart) < wait)
{
}
__weak uint32_t HAL_GetTick(void)
{
return uwTick;
}
Nothing happens more in this code I know the code is right but there is some error in the HAL_delay configuration.
After scratching my head for a day I tried uploading the following code
HAL_GPIO_TogglePin(led_GPIO_Port,led_Pin);
HAL_Delay(100);
And strange thing is that now my led is blinking only I have change the HAL_dealy value from 1000 to 100 and it works fine but, when using 1000 does not work at all.
So for testing, I gradually increased the delay value and I find that more than HAL_delay(400) it does not work.
Not able to find cause for this Any help will be appreciable.
As suggested by Tom I debugged uwTickFreq using STstudio.
and I got the following output waveform.
After that, I also uploaded the following code. And defined a variable as "unsigned long int a;"
HAL_GPIO_TogglePin(led_GPIO_Port,led_Pin);
HAL_Delay(100);
a= HAL_GetTick();
Now I debugged the value of a using STstudio. And strange the value of a becomes 0 once it reached around 300.
It seems like finally, I got the problem when I noticed the reset problem in the controller I searched around and find something here.
So I checked my optional bytes set in MCU with the STM32 cube programmer.
It was set as below.
Therefore I enabled these three optional bytes.
And the problem of reset was gone and I am now able to use the HAL_delay function properly and now the value of HAL_GetTick() is also increasing more than 300.
Still have one dought I think watchdog was causing reset but why it only cause that when I use the timing function.
I am currently playing with L152C Discovery board and trying to make simple clock that would use the RTC build into the STM32 and onboard Glass LCD with LCD HAL library configured via CubeMX.
But I am currently facing a problem I can't get my head around:
CubeMX does not have an option to enable segment mux in the LCD_CR register. I would like to enable it, because it would make the segment mapping easier.
So I thought, fine, I will make an direct register manipulation, enabling the mux (bit 7 in the LCD_CR).
I used the command LCD->CR |= LCD_CR_MUX_SEG; But even after executing the command, the MUX_SEG bit is still zero. (I checked in the debug session with command stepping and SFRs memory map)
Is there something that I am doing wrong? Or is there another way to change init parameters that CubeMX configured but does not have graphical implementation of this settings option?
The application is using FreeRTOS and I executed LCD->CR |= LCD_CR_MUX_SEG; after HAL_LCD_Init(&hlcd); so I sappose that the LCD peripheral clock is running (and segments are updating).
I recorded a short video showing this problem:
https://youtu.be/0X6Zu5EPudU
To be honest, I am not skilled at direct register manipulation, so I am probably doing something wrong.
Any help would be appreciated!😇
As #KIIV said:
RM0038 Liquid crystal display controller (LCD) Note: The VSEL, MUX_SEG, BIAS and DUTY bits are write protected when the LCD is enabled (ENS bit in LCD_SR to 1).
The LCD must be disabled when making changes to the above registers.
I encounter a problem currently with a custom STM32L151 board that I will try to explain here.
The program I am testing runs properly for some time, I get debug messages on puTTY as intended but at a time, the program seems to be "blocked".
It is pretty weird behaviour because the function which prints over UART is called (I put a breakpoint here to see if I reach this point) but I get no output on a terminal.
So I was wondering what could be the issue, if someone as an idea because I kinda run out of ideas to be honest, I tried to understand. I will assume there is no hardware issue, it is still possible but I do not think it could be that reason.
Also, the programs is aimed at receiving a FSK message and answering it and it seems that I have the same behaviour with the radio chip: I receive the message and send a response (I get the TxDone callback called which indicates that the FSK message has normally been sent but the device which waits for this response does not receive it).
So to sum up a bit: the program runs properly for a moment then "blocks" & I do not get any output anymore (debug or radio communication) but still runs (functions effectively called) and after a moment again, the program "unblocks" itself and runs properly again (debug messages work).
The device I work on is STM32L151 based, I work with Keil, UART config is: 19200 baudrate, 8 data bits, 1 stop bit, no parity, XON/XOFF flow control & the radio chip I use is SX1272.
If someone has any idea or any trail I can investigate on. If you need any further details, I am not sure I am accurate enough on the description of the problem but any help is appreciated.
we are currently evaluating to use an external SRAM for C/C++ heap storage on our platform using a STM32F439BI microcontroller.
The problem
Using the SRAM as storage for heap results in random hardfaults which are raised from buserrors/imprecice buserrors.
Without placing the heap on the SRAM, memory tests run successfully on the whole SRAM (8 bit/16 bit and 32 bit accesses).
Connecting a debugger I can observe these errors sometimes before a hardfault occurs. Most often a word is read from the SRAM and the CPU register fills with addresses of the following format: 0x-1F3-1F3 (- is most often '0', sometimes 'A' or '6'). The pattern '1F3' persists. If the same address is read again some lines further down the correct value is read (some other address in 0x60000000 space).
If I stop the program on a breakpoint at some point early in the program and step a few lines, I get these errors more frequently.
Further details
The SRAM is connected using the FMC/FSMC peripheral on FMC bank 1 and SRAM bank 1 and is therefore memory-mapped to address 0x60000000.
All settings for GPIO pins and FMC configuration are set from the startup file before main() executes or static objects are created.
The SRAM is the following: CY7C1041GN30
We connect all 16 data pins, all 18 address pins, BHE, BLE, OE, WE and CE to our controller. All pins are configured as push-pull-alternate-function, pull-up, AF_12 (FMC), very high speed. We enable clocks for all necessary pins and the clock for FMC. Note: Initially we started out without pull-up/down showing the same symptoms.
The controller runs with a clock speed of 168 MHz
As stated above, a memory test runs successfully
We use DMA for SPI, I2C and ADC data transfers
We frequently use interrupts, including external (pin) interrupts
We use the following timing settings:
AddressSetupTime: 2
AddressHoldTime: 4
DataSetupTime: 4
BusTurnAroundDuration: 1
CLKDivision: 2
DataLatency: 2
We configure the FMC as follows:
NSBank FMC_NORSRAM_BANK1,
DataAddressMux FMC_DATA_ADDRESS_MUX_DISABLE,
MemoryType FMC_MEMORY_TYPE_SRAM,
MemoryDataWidth FMC_NORSRAM_MEM_BUS_WIDTH_16,
BurstAccessMode FMC_BURST_ACCESS_MODE_DISABLE,
WaitSignalPolarity FMC_WAIT_SIGNAL_POLARITY_LOW,
WrapMode FMC_WRAP_MODE_DISABLE,
WaitSignalActive FMC_WAIT_TIMING_BEFORE_WS,
WriteOperation FMC_WRITE_OPERATION_ENABLE,
WaitSignal FMC_WAIT_SIGNAL_DISABLE,
ExtendedMode FMC_EXTENDED_MODE_DISABLE,
AsynchronousWait FMC_ASYNCHRONOUS_WAIT_DISABLE,
WriteBurst FMC_WRITE_BURST_DISABLE,
ContinuousClock FMC_CONTINUOUS_CLOCK_SYNC_ASYNC,
WriteFifo 0,
PageSize 0
We spend a lot of time of experimenting with longer timings and compared all the settings to examples including this one: Using STM32L476/486 FSMC peripheral
to drive external memories (although this one is for the STM32L4, I am fairly certain it applies to this controller as well)
Findings on similar problems
The problem sounds very similar to this errata sheet entry: "2.3.4 Corruption of data read from the FMC" but it also says the error is fixed in our revision of the controller (3)
I hope someone out there has seen this strange behaviour before and can help us. After over one week of debugging we expect some kind of error in the controller when interrupts/DMA accesses occur while the CPU accesses the SRAM (when we use it as heap, it is accessed very frequently). Hopefully you can shed some light on this topic.
Sorry for not getting back to you, internet.
Yes, we found out what the issue was (at least in our case). Problem was that the J-Link debugger we use is causing problems if it hangs above the power electronics on our pcb (it is mounted vertically). If we guide the ribbon cable out at the top (only digital electronics) the error disappears. So our guess is, that some noise from the electronics was caught up by the cable and directly injected into the JTAG port, which caused failures inside the MCU.
Just got a confirmation from ST, that there is a bug in the STM32F469 FMC that might cause incorrect values if the write fifo is disabled. The workaround is to have the fifo enabled. It is the same issue as in this F7 processor https://www.st.com/resource/en/errata_sheet/dm00145382.pdf
So I was programming on my board with a ATSAM4S8Bu using an Atmel-ICE debugger happily when suddenly I was assaulted by this error message any time I tried to debug or deploy to my board:
Failed to launch program
Error: unexpected chip identifier 0x00000000
This error also sometimes gets shouted at me:
Could not activate interface, but found DAP with ID 0x2ba01477.
How rude of it! I tried reasoning with it but it is not having any of it.
but seriously, it was fine one moment and the next this error has stopped me from further development so what does it mean and how do I fix this?
EDIT:
This error only seems to occur on my machine. It works on my colleagues, I tried reinstalling atmel-usb and atmel studio 6.2 but no luck :(
EDIT:
Some screen shots of the screen im shown in Tools->Device Programming and then trying to read the devices signature:
EDIT:
I also seem to get this error sometimes instead:
I've had this problem too and I have found a couple of solutions that I would like to share.
My PCB was using an ATSAM4E processor (that had never been programmed) with a Cortex debug header. I got the error message when I tried either method (SWD or JTAG).
Note: I was able to read the Device ID for a very short window after powering the PCB on or after pressing the reset button (Credit to Yaro and Yarooo). Often I would have to try multiple times to try and hit that short window. This confirmed to me that my circuit of the Cortex Debug header was correct.
jrb114 quotes in his post that there is an errata on the SAM3S datasheet that requires:
an external crystal or ceramic resonator on XIN/XOUT, or use the Main oscillator in bypass mode (applying a clock on XIN).
...
So what I did to make these boards work was provide a 1 MHz clock to XIN using a signal generator. Apply power to the PCB, then connect using the ATMEL-Ice. This connects fine. After that I set the GPNVM Bit 1 so we boot from flash, not SAMBA, programmed the device and it works fine.
My PCBs had an external crystal so I was a bit confused why my boards didn't work. So I put an oscilloscope on the XIN line and found that the crystal was not generating a waveform.
It turns out that on most of my boards, there was a short between one of the capacitors (for the crystal) to ground. No wonder my clock wasn't going.
On the other boards, the inductor that goes between VDD_OUT and VDD_PLL was not soldered correctly to the PCB, causing it to be open circuit.
Overall, it appears that this error is a result of not having a clock signal on XIN, whether it be incorrect wiring or not using an external crystal/resonator.