Problem with chipshouter

Hello, I have some problems with my chipshouter when I use a chipwhipser to trigger the chipshouter.
I use the hardware trigger in the shouter.
To show you the problem, I made a simple loop like this one with small delay:

for x in range(10000):

but after a few hundred loops, the chipshouter fails.
If i read the faults, i have this fault :

['fault_trigger_glitch', 'fault_temp_sensor']

I did another test like this one (i read every loop if the error are present, it already slows down the loop) :

for x in range(10000):
    if (cs.faults_current != []):

and after some loop the chipshouter reset! :

Reset_Exception                           Traceback (most recent call last)
<ipython-input-35-796435fac287> in <module>
      4     scope.glitch.manual_trigger()
      5     time.sleep(0.01)
----> 6     if (cs.faults_current != []):
      7         print(cs.faults_current)
      8         print(cs.faults_latched)

~/.local/lib/python3.9/site-packages/chipshouter/ in faults_current(self)
    496         """
--> 497         return self.com_api.get_faults_current()
    499     @faults_current.setter

~/.local/lib/python3.9/site-packages/chipshouter/ in get_faults_current(self)
   1210         :returns (list): List of fault names that exist currently
   1211         """
-> 1212         request = self.get_option_from_shouter([t_16_Bit_Options.FAULT_ACTIVE], BP_TOOL.REQUEST_16)
   1213         return self.__get_faults_list(self.config_16.faults_current)

~/.local/lib/python3.9/site-packages/chipshouter/ in get_option_from_shouter(self, options, req_type)
   1053         val = self.build_request(options, req_type)
-> 1054         r   = self.interact_with_shouter(val)
   1055         self.parse_protocol(r)

~/.local/lib/python3.9/site-packages/chipshouter/ in interact_with_shouter(self, data)
   1026         packet.extend(data)
-> 1028         rval = self.__send_with_retries(data)
   1029         return rval

~/.local/lib/python3.9/site-packages/chipshouter/ in __send_with_retries(self, data, retries)
    997             retries -= 1
    998             self.s_write(data)
--> 999             r = self.s_read()
   1001             if len(r) == 0:

~/.local/lib/python3.9/site-packages/chipshouter/ in s_read(self, timeout)
    137             # End logging
    138             if Connection.START_UP_STRING in data:
--> 139                 raise Reset_Exception('Shouter has reset')
    141             if start < 0 or end < 0 or end < start:

Reset_Exception: Shouter has reset

I tried to integrate a triggerstate and to modify absent_temp but it does not change anything.
I have the fw 2.0.1
I found a temporary solution by setting large delays (500ms) and handling exceptions but this slows down the loops a lot!
Is it possible to have a solution or a way to write your own firmware?
Thank you.


We’ve got firmware in progress that should fix the reset issue at least. We’re currently working remote due to COVID, but I should be able to pop in and build that version for you if you DM be your board ID.


hello Alex, thank you for your answer, i send my boardid in pm.

today I still haven’t received the firmware, is this normal?

Personally, I’m starting to lose patience.
I summarize the situation of my problem.
At first I wrote directly to the support 28 days ago but I did not receive any answer. I also wrote a private message to an admin … no answer.
I then wrote on the forum 21 days ago. 10 days later I received a reply offering me a new firmware but since then … no more replies and no new firmware!
I sent other private messages and emails to the support but still … no answer.

At the time I found the chipwhipser support nice and fast but today for the chipshouter I have the impression that nobody cares and can’t solve the problem!
The firmware contains several bugs and I don’t find this normal for a product with more than 3000$, it looks like a toy firmware. I even wonder if the chipshouter wouldn’t glitched itself.

Now I have another question: is it possible to send its own firmware using the original bootloader (the bootloader requires an encrypted and probably signed file but is there a bypass for that). Otherwise I could use the pdi port directly but I have to open the case and probably lose the original bootloader.

thank you for the answer in the future!