Posts by giusloq

    I'm replying to this my old post because I encountered another strange effect related to this issue, I think.

    Even with this workaroud, when I call TEXT_SetText("Commutazione veloce") and the current text is "Commutazione lenta", the widget is not updated. Note that the new string has a different length then the old one.

    As usual I'm using NXP emWin binaries 6.16c. The bug is present in this version, but in this case the string lengths are different, so I don't know if it is another bug or the same bug that triggers in other conditions.

    Actually I'm using emWin with a small 2.4" display with ILI9341 controller, used in 16 bits data mode. It works well.

    Now I have to replace the display with one from another supplier. The new display is quite similar, but integrates the controller ST7789V3, always in 16 bits data mode. Is it compatible with emWin?

    In the manual I read ST7789 and ILI9341 are controllers that share the same driver: GUIDRV_FLEXCOLOR_F66709. However the manual says a generic ST7789. What should I expect with V3 variant of this chip? I don't know what are the differences between V3 and older versions, if critical features have changed.

    Do you confirm that this bug appeared for the first time in 61603 (6.16c)?

    Is it safe to call WM_NotifyParent() before TEXT_SetText()? Shouldn't it be better to call it after?

    I experienced the same problem with v6.16c (NXP binaries), so this bug is present at least since this version.
    Unfortunately the last NXP emWin binary is v6.16c, so I can't upgrade.

    What do you think of this workaround?

    Writing this piece of code, another question arose. Is it possible to know the length of a text in a TEXT widget? TEXT_GetText() copies the text of a TEXT widget in a buffer, but I don't know how to size this buffer in advance. I think it should be nice to have a TEXT_GetTextLen().

    I read somewhere in the forum that there was a bug exactly with TEXT_SetText() when the length of the text does not change. I think I encountered it.

    Could you give me more details of which versions are affected of this bug? I read that 6.18c fixed this bug.

    I noticed this bug on a simulator under Windows (SeggerEval_WIN32_MSVC_MinGW_GUI_V616.zip). I'm using it because my embedded platform is equipped with MCU from NXP and the emWin last emWin release is v6.16c. Is this version affected of this bug?

    Output is

    Code
    TEXT_GetText(92)=Registro eventi
    WM_GetInvalidRect(92)=0
    TEXT_GetText(92)=Registro 1..2/9
    WM_GetInvalidRect(92)=0

    How is possible that TEXT widget area is not invalidated after setting a new text? Indeed I don't see any visible changes.
    If I call WM_InvalidateWindow() on the widget, the behaviour is correct and I see the new text in the TEXT widget.

    It's an oddy behaviour, because it may depend on the first text set during TEXT_CreateEx(). I create the TEXT widget with the following code:

    C
    TEXT_Handle hTxt;
    hTxt = TEXT_CreateEx(TOPBAR_LEFT_WIDTH, 0, xSize - 2 * TOPBAR_LEFT_WIDTH, TOPBAR_HEIGHT, hWin, WM_CF_SHOW, TEXT_CF_HCENTER | TEXT_CF_VCENTER, TEXT_TITLE, "Registro eventi");
    TEXT_SetBkColor(hTxt, GUI_RED);
    TEXT_SetTextColor(hTxt, GUI_WHITE);
    TEXT_SetFont(hTxt, TOPBAR_FONT);

    If I change the text in TEXT_CreateEx() it is possible that afterwards TEXT_SetText() will invalidate the widget and the new text is drawn.

    It seems to me it depends of the length of the old and new string: if they are the same, TEXT_SetText() sometimes decides to not invalidate the text area.

    From what I've understood after reading User's Manual of LPC546xx MCUs by NXP, internal Flash is organized of uniform 32kB sectors and uniform 256B pages. There's a command to erase one or more sectors and there's a command to erase one or more pages (that must be all inside a sector).

    In my project I'd like to have a bootloader at the beginning of internal Flash with a size of 20kB. So the application should start at address 20480=0x5000.

    I'm using MCUXpresso IDE and I think I've configured everything well for both projects (bootloader and application). What happens when I launch Debug configuration of application project? I suspect JLink erases the entire first sector, so erasing bootloader too. Similar thing happens when I launch bootloader Debug configuration that erases the full first sector (so overwriting application, if any was written before).

    Is there any way to change the erase from a sector boundary to a page boundary?

    50116485

    However we are testing ground connections. We measured around 20Vac between board ground and J-Link ground, before connecting them.

    I'm suspecting that the problem can arise when I hot-plug J-Link flat cable to the board.

    The board is supplied from an AC/DC with its metallic case connected to earth and the reference of its output +12Vdc is connected to earth too. The PC is a standard desktop computer connected to a UPS.
    I don't know why there's such a residual alternate voltage, most probably caused by mains 230Vac.

    I make a good connection between metallic case of my desktop PC and metallic case of AC/DC that powers the board and now I don't see 20Vac residual voltage anymore. Maybe this could be the cause of my issues.

    What do you suggest to have a good workbench in this scenario?

    I highly suspect that this is connected to your hardware.

    Ok, but this happened on three different boards. If there's a problem on my hw, it is repetitive on multiple boards and MCUs.
    This isn't the first board we design, we don't explain what is happening.

    Does the same issue appear when using an evaluation board?

    Until now no, I have these issues only on custom boards. Anyway they are very similar to EVB, at least for SWD lines connection.
    Only LPC546xx EVB has protection diodes on SWD lines, while I don't have them on my custom board.


    I would suggest to measure the voltage between VDD and GND and compare it to the evaluation board.

    It's 3.3V as normal.

    Also, you could connect an oscilloscope to the SWD signals to check and compare them with VTref.

    On boards that mount good MCUs, SWD lines swing normally between GND and VDD. As I wrote, if I connect broken MCUs, SWDIO line isn't able to go to GND and to VDD. Look at the picture attached. The upper trace is VDD, while the lower trace is SWDIO. The reference for both channels are at the same point. It's evident there's some problem with SWDIO. he problem is inside MCU.

    I suspect something has broken inside the MCU on SWD lines, but only J-Link is attached to these lines.

    After some investigations, I found something interesting on SWDIO pin. When the probe is able to connect to the MCU, SWDIO signal goes high and low without problems: I can see 0V and Vcc on scope.
    On MCUs that are broken, SWDIO swings in a more restricted voltage range: for example from 1V to 2V.

    It seems SWDIO is broken inside MCU, but this happend THREE times! Is it possible that J-Link is responsible for this? Is it possible that a malfunctioning J-Link could apply a somewhat high voltage on SWD lines during programming?

    I'm thinking that J-Link could be the cause of all these issues because they happened recently three times with three different MCUs and three different custom boards. I used this J-Link probe for many years without any problems on many MCUs, but recently I have all these issues.

    Hello Fabian,

    I know it's incredible, but three times I experienced this problem on three differrent PCBs and MCUs: LPC54101, LPC54618 and LPC54606. J-Link returns the error "Could not connect to target", it seems SWD access is locked on the MCU.

    I don't know what's the problem is, but I'm starting thinking of the J-Link that could be malfunctioning (even if it works great with other boards and MCUs).

    I have the latest J-Link software and I tried to restart from a blank project, without any success.

    In all three cases, I am able to enter USART ISP Boot and erase internal Flash memory, but SWD access again is impossible even after chip erase.

    Could be the J-LINK malfunctioning and destroy SWD of connected MCUs?

    Quote from Fabian

    Usually such a Problem is connected to one of the three following points.
    The application
    1) re-configures the debug pins as GPIOs.

    I think this is not my case for a simple reason. I can enter ROM Bootloader by keeping low one ISP bootstrap pin. When in Bootloader, my application doesn't run at all. However, even when the ROM Bootloader is active, SWD doesn't work (while on EVB I can connect through SWD during Bootloader).

    Quote from Fabian

    2) enables chip security (by accident or on purpose)

    At the beginning I was thinking of this. LPC546XX has a method, called ECRP, that could lock SWD access by a magic work in Flash or writing some bits in OTP memory. However I can erase entire Flash (through UART ROM Bootloader) and the bits in OTP memory seems at their default values (identical to EVB).

    Quote from Fabian

    3) makes use of low-power modes that disable all debug related clocks inside the chip.

    Not in my case, when I enter ROM Bootloader.

    Quote from Fabian

    If you are sure that the replaced MCU is soldered correctly on the PCB, I would advice to check if the signals between MCU and debug header are actually connected through.
    Maybe the lanes on the PCB were damaged or some peripheral is active that influences the signal integrity of the debug lanes.

    Yes, MCU is soldered correctly because I can see SWDIO and SWCLK pins toggling (directly on the debug header connector) when the application re-configures them as GPIO.

    I don't know what to think.

    I'm working on two different prototypes of two different boards with two different MCUs of the same family: LPC54618 and LPC54628 by NXP.

    Initially J-Link is able to make a good connection via SWD and I can download new firmware, debug and so on.

    However, it happened two times (the first with one board and the second on another board) that J-Link wasn't able to connect to the MCU anymore. In the first case, I mount a completely new PCB (with a new MCU) and now it is working well, but the original MCU seems bricked.
    In the second case, I decided to replace the MCU on the board, but the error is still there: J-Link can't connect via SWD.

    After some tests, I understood that the MCU is fully functional: the application that resides in the Flash runs without any problem. I'm also able to enter ROM UART Bootloader via ISP pins and I'm able to download a new firmware via UART.

    It seems only SWD port/pins is locked, but I don't know why.

    I investigated ECRP (a method from NXP that enables some restrictions on the MCU, i.e. SWD access), but it seems all is allowed and unlocked.

    I already asked NXP guys, but without success at the moment. I write here, maybe it's something related to J-Link and not NXP.

    What you are describing is not a memory leak, but normal behavior of emWin's memory management.

    It was really a memory leak, because after some open and close the child window, emWin crashes for an out of memory error. However I found the solution, it wasn't a problem in emWin, I was creating the window two times, but deleting only one instance.

    Probably the sentence in the manual explains why GUI_ALLOC_GetNumFreeBytes() doesn't return the same number after one WM_CreateWindow() and one WM_DeleteWindow(). This is ok, but the number should be almost the same with the use (opening and closing windows), otherwise a memory leak is really present.

    For this reason, I'd like to know how to monitor emWin dynamic memory to be sure there isn't any memory leak.


    Also, from my point of view there is no need to delete the window by sending a message first, since the message would get handled directly after it has been sent. So it would make no difference if you call WM_DeleteWindow() in instead of sending the custom message.

    Yes, you're right, but the child window doesn't know if the button released event should cause the window close or not. Only the background callback (in another C module) knows it.

    I create a child window (child of background window) that has a button. When the button is pressed, in the event WM_NOTIFY_PARENT/WM_NOTIFICATION_RELEASED I call WM_SendMessage() to send a custom message to main/background window.

    During processing this custom message (in the callback of background window), I want to call WM_DeleteWindow() to delete the child window. Is it possible? It seems it works, but after some tests it seems there are some memory leaks.

    I can't call WM_DeleteWindow() from the child window, because only background window knows if it's time to delete the child window.

    I'm using 5.32.

    I'm using an edited JLinkDevices.xml to add a custom Flash bank (actually a SPI Flash connected to LPC1788):


    Code
    <DataBase>
      <Device>
       <ChipInfo Vendor="NXP" Name="LPC1788" />
       <FlashBankInfo Name="SST26VF016B on LPC1788" BaseAddr="0xA0080000" MaxSize="0x800000" Loader="lpc1788_spiflash_loader.elf" LoaderType="FLASH_ALGO_TYPE_OPEN" />
      </Device>
    </DataBase>

    What's the behaviour of erase command of J-Link Commander tool? Does it erase only internal Flash memory of LPC1788 or will it try to use Flash Loader to erase the added Flash bank?

    I'm creating a Flash Loader for a SPI Flash connected to a SPI peripheral of LPC1788. After issuing sector erase command, you can know when the erase is complete by polling busy bit in the STATUS register.

    How do J-Link know when a sector erase is complete? In FlashDevice structure there are two members: TimeoutProg and TimeoutErase. Does it mean that J-Link waits for this maximum timeout to know when the erase is complete?

    Another question. Should the function EraseSector() return only after the erase is complete (i.e. after busy flag of SPI Flash comes back to zero)? Could EraseSector() return just after issuing the erase command?