Search Results

Dear Venkat, File upload support has been officially introduced with the latest embOS/IP V2.10 . Best regards, Oliver

Hello Harshith, For the mentioned eval board we actually have the embOS trial package only. I have added it to our ToDo list but can not give you an estimate of when it will be done. If this is not acceptable for your time schedule you can do the following: - In general you could take another eval package for a ARM7 CPU from our website featuring embOS/IP as the embOS/IP library fits for all compatible architectures and all drivers are included in the trial library. The same applies to emUSB. Th…

Dear Zaheer, Serial Wire Debugging (SWD) for STM8 devices uses a different interface than SWD for Cortex-M devices. Unfortunately both are simply named by what they are. At the moment only our Flasher STM8 is supporting the interface of STM8 devices. A J-Link for STM8 is not planned at the moment. Best regards, Oliver

Dear pawdrexel, This functionality is not documented and is therefore not meant to be used. As you already mentioned, this is code that is a leftover from the original Interniche stack. This code seems to be overseen during cleanup operations. At the moment our stack does not support this feature and it is not planned to implement this feature the way it was. Quote: “ I am getting more frustrated with and disappointed by embOS/IP. ” If you feel that there is a problem with embOS/IP and the funct…

Hi dshortridge, I had a look at your provided sources but could not see anything suspicious in it. Does the sample we provide for download from our website compile with your Keil installation ? You can find our eval package at the following location: segger.com/keil-mcb1760-eval-board.html Can you provide us with a complete project except for the emWin sources/objects so we can test it for ourselves ? Please only remove the emWin files out of the project physically but leave them in the project …

Hi URoman, I think the problem is that after you have programmed one device you do not disconnect from the target. The Flasher will automatically disconnect only if a power change of the target is detected. As with the socket board I have been testing this the Flasher does not recognize a plain MCU change. Therefor expecting the device already being unlocked and prepared for programming from the previous attempt. Does it help to do a clean disconnect before trying to program the next target ? To…

Hi, from your log I do not see a disconnect happen between the programming attempt that is successful and the one that fails. Therefor I have some further questions: - Is your target powered externally or powered via Flasher ? - Are you dealing with Read Out Protection (byte @0x4800) when programming ? - Has the target been disconnected or changed during the several programming attempts ? Do you try to program the same device twice ? Best regards, Oliver

Hi URoman, Quote from URoman: “but to program the next one, it always appears an error.” Regarding your last post I think you are using a STM8S903K3, right ? Can you give us some more detail about what error is occuring by a screenshot of the error or by an error message that is output in the log window ? Does this problem occur only when you try to program different chips or is it happening when you reconnect to the same chip again after disconnecting it ? Best regards, Oliver

Dear URoman, Sorry for not getting back via mail earlier. You are right. We have added it to our latest beta version as we currently do not have this exact type of MCU to test. You can download the latest beta software (V1.09) from the following location: segger.com/cms/flasher-stm8-beta-software-version.html Can you confirm that this version is working and able to flash the STM8S903K3 MCU ? Best regards, Oliver

Hi Rui, Which IDE are you using ? If you are using IAR EWARM can you check if it is works if you disable any terminal output for example via commenting out any printf() or puts() calls ? Best regards, Oliver

Hi sompop, For STM8 devices the option bytes are memory mapped at addr. 0x4800 and can be programmed using Flasher STM8 like any other memory addr. in your device. If you do not already have output that utilizes option bytes the simplest way would be to read back the memory from 0x4800 and modify the option bytes in this area. Further meaning of option bytes and what their meaning is on your target can be achieved from the device specific manuals available from ST. Best regards, Oliver

Thank you for the update. Glad to hear that you found out the problem. Might help others here as well. Closed.

Hello, We have tried to reproduce the problems you are reporting using a STM8S103K3. To be able to give this case a deeper investigation we would need to get some more information about your current status: - Do you use the latest SEGGER software for Flasher STM8 that is available (V1.06b at this moment) ? - When using the STM8 Commander, does it report that a target chip has been found "Found STM8 (xMHz)" ? - Are you able to read memory using the STM8 Commander by using the command "mem" ? Quot…

Hello joubin, For reprogramming a target which is read out protected or for a target you do not know it is recommended to set the "Unsecure chip" option for AUTO programming. I recommend you to use the latest beta available from the following location: segger.com/cms/flasher-stm8-beta-software-version.html This might help you as well if you run into trouble with read out protection as the beta uses a new connect sequence and completely revised flash algorithm. Regards, Oliver

Hello joubin, To be able to reproduce your problem we need some more information: - Are you trying to program option bytes ? - If you are trying to program option bytes which values do you try to program ? (most important the first 16 bytes) - Is the target secured by read out protection or does it use user boot code area ? - What option do you use for AUTO programming ? (can be found in menu "Options->Project settings..." in tab production) Regards, Oliver

Open the project options of your RAM configuration and click "Linker" from the left hand menu. Switch to the "List" tab and ensure the "Generate linker listing" and "Module summary" checkboxes are checked. Compile your RAM project, IAR will generate a .lst file which can be found in the file tree with the same looking name as the executable. Open it and scroll to the end of the file, there will be a total summary of how much space your program needs. Best regards, Oliver

Hi, Do you use RAM or FLASH configuration in your project? For experimental states it is recommended to use a RAM configuration and to switch to a FLASH configuration if you are sure that your application runs stable. Best regards, Oliver